Institute for the Design of Advanced Energy Systems (IDAES)Â¶
Project GoalsÂ¶
The Institute for the Design of Advanced Energy Systems (IDAES) will be the worldâ€™s premier resource for the development and analysis of innovative advanced energy systems through the use of process systems engineering tools and approaches. IDAES and its capabilities will be applicable to the development of the full range of advanced fossil energy systems, including chemical looping and other transformational CO_{2} capture technologies, as well as integration with other new technologies such as supercritical CO_{2}. In addition, the tools and capabilities will be applicable to renewable energy development, such as biofuels, green chemistry, Nuclear and Environmental Management, such as the design of complex, integrated waste treatment facilities.
Collaborating institutionsÂ¶
The IDAES team is comprised of collaborators from the following institutions:
 National Energy Technology Laboratory (Lead)
 Sandia National Laboratory
 Lawrence Berkeley National Laboratory
 CarnegieMellon University (subcontract to LBNL)
 West Virginia University (subcontract to LBNL)
Contact, contributions and more informationÂ¶
General, background and overview information is available at the IDAES main website. Framework development happens at our GitHub repo where you can report issues/bugs or make contributions. For further enquiries, send an email to: <idaessupport@idaes.org>
ContentsÂ¶
InstallationÂ¶
Installation using DockerÂ¶
One way to install the IDAES PSE Framework is by using the prebuilt Docker image.
A Docker image is essentially an embedded instance of Linux (even if you are using Windows or Mac OSX) that has all the code for the IDAES PSE framework preinstalled. You can run commands and Jupyter Notebooks in that image. This section describes how to set up your system, get the Docker image, and interact with it.
Install Docker on your systemÂ¶
Install the community edition (CE) of Docker (website: https://docker.io).
Start the Docker daemon. How to do this will depend on your operating system.
 OS X
You should install Docker Desktop for Mac. Docker should have been installed to your Applications directory. Browse to it and click on it from there. You will see a small icon in your toolbar that indicates that the daemon is running.
 Linux
Install Docker using the package manager for your OS. Then start the daemon. If you are using Ubuntu or a Debianbased Linux distro, the Docker daemon will start automatically once Docker is installed. For CentOS, start Docker manually, e.g., run
sudo systemctl start docker
. Windows
You should install Docker Desktop for Windows. Docker will be started automatically.
Get the IDAES Docker imageÂ¶
You need to get the ready made Docker image containing the source code and solvers for the IDAES PSE framework. This image is available for download from DockerHub (an online portal where Docker images are stored). Images on DockerHub are versioned according to the release version. See the Releases_ page on GitHub for information about what is different about each version.
If you want the latest version, simply use the tag â€ślatestâ€ť as the version number. Thus, running the following in a terminal will download the latest version:
docker pull idaes/jupyterhub:latest
.. _Releases: https://github.com/IDAES/idaespse/releases
Run the IDAES Docker imageÂ¶
To start the Docker image, use a graphical user interface or a console or shell commandline interface.
From the commandline, if you want to start up the Jupyter Notebook server, e.g. to view and run the examples and tutorials, then run this command:
$ docker run p 8888:8888 it idaes/jupyterhub
... <debugging output from Jupyter>
...
Copy/paste this URL into your browser when you connect for the first time,
to login with a token:
http://(305491ce063a or 127.0.0.1):8888/?token=812a290619211bef9177b0e8c0fd7e4d1f673d29909ac254
Copy and paste the URL provided at the end of the output into a browser window
and you should get a working Jupyter Notebook. You can browse to the examples
directory under /home/idaes/examples
and click on the Jupyter Notebooks to
open them.
To interact with the image directly from the commandline (console), you can run the following command:
$ docker run p 8888:8888 it idaes/jupyterhub /bin/bash
jovyan@10c11ca29008:~$ cd /home/idaes
...
To install the IDAES PSE framework, follow the set of instructions below that are appropriate for your needs and operating system. If you get stuck, please contact idaessupport@idaes.org.
The Docker installation works on any platform that supports Docker, but of course requires installation of, and some understanding of, Docker itself to operate.
The OS specific instructions provide information about installing Miniconda. If you already have a Python installation you prefer, you can skip to the generic install procedure.
System  Section 

Linux  Linux 
Windows  Windows 
Mac OSX  Mac/OSX 
Generic  Generic install 
Dockerbased  Installation using Docker 
WindowsÂ¶
Install Miniconda
 Download: https://repo.anaconda.com/miniconda/Miniconda3latestWindowsx86_64.exe
 Install anaconda from the downloaded file in (1).
 Open the Anaconda powershell (Start > â€śAnaconda Powershell Promptâ€ť).
 In the Anaconda Powershell, follow the Generic install instructions.
LinuxÂ¶
Install Miniconda
Download: https://repo.anaconda.com/miniconda/Miniconda3latestLinuxx86_64.sh
Open a terminal window
Run the script you downloaded in (1).
Follow the Generic install instructions.
The IPOPT solver depends on the GNU FORTRAN libraries, which are not bundled with it. Unless you know that these are already installed on your system, you should manually install them using â€śaptgetâ€ť, â€śyumâ€ť or other appropriate package manager.
aptget (Debian or Ubuntu based distributions):
aptget install libgfortran3
yum (RedHat based distributions):
yum install libgfortran
Mac/OSXÂ¶
Install Miniconda
 Download: https://repo.anaconda.com/miniconda/Miniconda3latestMacOSXx86_64.sh
 For the next steps, open a terminal window
 Run the script you downloaded in (1).
 Follow the Generic install instructions.
Generic installÂ¶
Once you have Conda installed, the remaining steps, performed in either the Anaconda Powershell (Prompt) or a Linux terminal, are the same.
If you are familiar with Python/Conda environments, you will probably
want to create a new environment for your IDAES installation before
starting to install Python and/or Conda packages,
e.g., conda create n <env> python=3.7
then conda activate <env>
.
If you are not familiar with these commands, donâ€™t worry, this is
an optional step.
Install IDAES
Install IDAES with pip:
pip install idaespse
Run the idaes command to install the compiled binaries:
idaes getextensions
Note
The IDAES binary extensions are not yet supported on Mac/OSX
Run tests on unit models:
pytest pyargs idaes W ignore
You should see the tests run and all should pass to ensure the installation worked. You may see some â€śErrorâ€ť level log messages, but they are okay, and produced by tests for error handling. The number of failed and succeed test is reported at the end of the pytest output. You can report problems on the Github issues page (Please try to be specific about the command and the offending output.)
IDAES Modeling StandardsÂ¶
Contents
Model Formatting and General StandardsÂ¶
The section describes the recommended formatting used within the IDAES framework. Users are strongly encouraged to follow these standards in developing their models in order to improve readability of their code.
Headers and MetadataÂ¶
Model developers are encouraged to include some documentation in the header of their model files which provides a brief description of the purpose of the model and how it was developed. Some suggested information to include is:
 Model name,
 Model publication date,
 Model author
 Any necessary licensing and disclaimer information (see below).
 Any additional information the modeler feels should be included.
Coding StandardÂ¶
All code developed as part of IDAES should conform to the PEP8 standard.
Model OrganizationÂ¶
Whilst the overall IDAES modeling framework enforces a hierarchical structure on models, model developers are still encouraged to arrange their models in a logical fashion to aid other users in understanding the model. Model constraints should be grouped with similar constraints, and each grouping of constraints should be clearly commented.
For property packages, it is recommended that all the equations necessary for calculating a given property be grouped together, clearly separated and identified by using comments.
Additionally, model developers are encouraged to consider breaking their model up into a number of smaller methods where this makes sense. This can facilitate modification of the code by allowing future users to inherit from the base model and selectively overload submethods where desired.
CommentingÂ¶
To help other modelers and users understand the how a model works, model builders are strongly encouraged to comment their code. It is suggested that every constraint should be commented with a description of the purpose of the constraint, and if possible/necessary a reference to a source or more detailed explanation. Any deviations from standard units or formatting should be clearly identified here. Any initialization procedures, or other procedures required to get the model to converge should be clearly commented and explained where they appear in the code. Additionally, modelers are strongly encouraged to add additional comments explaining how their model works to aid others in understanding the model.
Units of Measurement and Reference StatesÂ¶
Due to the flexibility provided by the IDAES modeling framework, there is no standard set of units of measurement or standard reference state that should be used in models. This places the onus on the user to understand the units of measurement being used within their models and to ensure that they are consistent.
The IDAES developers have generally used SI units without prefixes (i.e. Pa, not kPa) within models developed by the institute, with a default thermodynamic reference state of 298.15 K and 101325 Pa. Supercritical fluids have been consider to be part of the liquid phase, as they will be handled via pumps rather than compressors.
Standard Variable NamesÂ¶
In order for different models to communicate information effectively, it is necessary to have a standard naming convention for any variable that may need to be shared between different models. Within the IDAES modeling framework, this occurs most frequently with information regarding the state and properties of the material within the system, which is calculated in specialized property blocks, and then used in others parts of the model. This section of the documentation discusses the standard naming conventions used within the IDAES modeling framework.
Standard Naming FormatÂ¶
There are a wide range of different variables which may be of interest to modelers, and a number of different ways in which these quantities can be expressed. In order to facilitate communication between different parts of models, a naming convention has been established to standardize the naming of variables across models. Variable names within IDAES follow to the format below:
{property_name}_{basis}_{state}_{condition}
Here, property_name is the name of the quantity in question, and should be drawn from the list of standard variable names given later in this document. If a particular quantity is not included in the list of standard names, users are encouraged to contact the IDAES developers so that it can be included in a future release. This is followed by a number of qualifiers which further indicate the specific conditions under which the quantity is being calculated. These qualifiers are described below, and some examples are given at the end of this document.
Basis QualifierÂ¶
Many properties of interest to modelers are most conveniently represented on an intensive basis, that is quantity per unit amount of material. There are a number of different bases that can be used when expressing intensive quantities, and a list of standard basis qualifiers are given below.
Basis  Standard Name 

Mass Basis  mass 
Molar Basis  mol 
Volume Basis  vol 
State QualifierÂ¶
Many quantities can be calculated either for the whole or a part of a mixture. In these cases, a qualifier is added to the quantity to indicate which part of the mixture the quantity applies to. In these cases, quantities may also be indexed by a Pyomo Set.
Basis  Standard Name  Comments 

Component  comp  Indexed by component list 
Phase  phase  Indexed by phase list 
Phase & Component  phase_comp  Indexed by phase and component list 
Total Mixture  No state qualifier 
Phase  Standard Name 

Supercritical Fluid  liq 
Ionic Species  ion 
Liquid Phase  liq 
Solid Phase  sol 
Vapor Phase  vap 
Multiple Phases  e.g. liq1 
Condition QualifierÂ¶
There are also cases where a modeler may want to calculate a quantity at some state other than the actual state of the system (e.g. at the critical point, or at equilibrium).
Basis  Standard Name 

Critical Point  crit 
Equilibrium State  equil 
Ideal Gas  ideal 
Reduced Properties  red 
Reference State  ref 
Thermophysical and Transport PropertiesÂ¶
Below is a list of all the thermophysical properties which currently have a standard name associated with them in the IDAES framework.
Variable  Standard Name 

Activity  act 
Activity Coefficient  act_coeff 
Bubble Pressure  pressure_bubble 
Bubble Temperature  temperature_bubble 
Compressibility Factor  compress_fact 
Concentration  conc 
Density  dens 
Dew Pressure  pressure_dew 
Dew Temperature  temperature_dew 
Diffusivity  diffus 
Diffusion Coefficient (binary)  diffus_binary 
Enthalpy  enth 
Entropy  entr 
Fugacity  fug 
Fugacity Coefficient  fug_coeff 
Gibbs Energy  energy_gibbs 
Heat Capacity (const. P)  cp 
Heat Capacity (const. V)  cv 
Heat Capacity Ratio  heat_capacity_ratio 
Helmholtz Energy  energy_helmholtz 
Henryâ€™s Constant  henry 
Internal Energy  energy_internal 
Mass Fraction  mass_frac 
Material Flow  flow 
Molecular Weight  mw 
Mole Fraction  mole_frac 
pH  pH 
Pressure  pressure 
Speed of Sound  speed_sound 
Surface Tension  surf_tens 
Temperature  temperature 
Thermal Conductivity  therm_cond 
Vapor Pressure  pressure_sat 
Viscosity (dynamic)  visc_d 
Viscosity (kinematic)  visc_k 
Vapor Fraction  vap_frac 
Volume Fraction  vol_frac 
Reaction PropertiesÂ¶
Below is a list of all the reaction properties which currently have a standard name associated with them in the IDAES framework.
Variable  Standard Name 

Activation Energy  energy_activation 
Arrhenius Coefficient  arrhenius 
Heat of Reaction  dh_rxn 
Entropy of Reaction  ds_rxn 
Equilibrium Constant  k_eq 
Reaction Rate  reaction_rate 
Rate constant  k_rxn 
Solubility Constant  k_sol 
Solid PropertiesÂ¶
Below is a list of all the properties of solid materials which currently have a standard name associated with them in the IDAES framework.
Variable  Standard Name 

Min. Fluidization Velocity  velocity_mf 
Min. Fluidization Voidage  voidage_mf 
Particle Size  particle_dia 
Pore Size  pore_dia 
Porosity  particle_porosity 
Specific Surface Area  area_{basis} 
Sphericity  sphericity 
Tortuosity  tort 
Voidage  bulk_voidage 
Naming ExamplesÂ¶
Below are some examples of the IDAES naming convention in use.
Variable Name  Meaning 

enth  Specific enthalpy of the entire mixture (across all phases) 
flow_comp[â€śH2Oâ€ť]  Total flow of H2O (across all phases) 
entr_phase[â€śliqâ€ť]  Specific entropy of the liquid phase mixture 
conc_phase_comp[â€śliqâ€ť, â€śH2Oâ€ť]  Concentration of H2O in the liquid phase 
temperature_red  Reduced temperature 
pressure_crit  Critical pressure 
Core LibraryÂ¶
Core ContentsÂ¶
IDAES Framework ConfigurationÂ¶
The IDAES framework can be configured with configuration files in TOML format.
Supplying a configuration file is optional. Currently this file sets logging
configuration and modules that should be searched for plugins. The
configuration is done when first importing any idaes.* module. The IDAES
framework will first attempt to read a userlevel configuration file at
%LOCALAPPDATA%\idaes\idaes.conf
on Windows or $HOME/.idaes/idaes.conf
on
other operating systems (e.g. Linux or Mac). Next if an idaes.conf file exists
in the working directory it will be read. Configuration files in the working
directory will override settings in the userlevel configuration file. The user
level configuration file will override default settings. Not all setting need
to be set in a configuration file.
An example configuration file is given below with the default settings.
[plugins]
required = []
optional = []
[logging]
version = 1
disable_existing_loggers = false
[logging.formatters.f1]
format = "%(asctime)s  %(levelname)s  %(name)s  %(message)s"
datefmt = "%Y%m%d %H:%M:%S"
[logging.handlers.console]
class = "logging.StreamHandler"
formatter = "f1"
stream = "ext://sys.stderr"
[logging.loggers.idaes]
level = "INFO"
handlers = ["console"]
The Python dictConfig method is used to set up the logger. The required and optional elements under plugins are string lists of modules to search for Pyomo style plugins. Any failure to import plugins in the required modules will raise an exception, while any failure to import optional plugins will only result in the exception being logged and execution continuing.
Process BlocksÂ¶
ExampleÂ¶
ProcessBlock is used to simplify inheritance of Pyomoâ€™s Block. The code below provides an example of how a new ProcessBlock class can be implemented. The new ProcessBlock class has a ConfigBlock that allows each element of the block to be passed configuration options that affect how a block is built. ProcessBlocks have a rule set by default that calls the build method of the contained ProcessBlockData class.
from pyomo.environ import *
from pyomo.common.config import ConfigValue
from idaes.core import ProcessBlockData, declare_process_block_class
@declare_process_block_class("MyBlock")
class MyBlockData(ProcessBlockData):
CONFIG = ProcessBlockData.CONFIG()
CONFIG.declare("xinit", ConfigValue(default=1001, domain=float))
CONFIG.declare("yinit", ConfigValue(default=1002, domain=float))
def build(self):
super(MyBlockData, self).build()
self.x = Var(initialize=self.config.xinit)
self.y = Var(initialize=self.config.yinit)
The following example demonstrates creating a scalar instance of the new class.
The default
key word argument is used to pass information on the the
MyBlockData ConfigBlock.
m = ConcreteModel()
m.b = MyBlock(default={"xinit":1, "yinit":2})
The next example creates an indexed MyBlock instance. In this case, each block is
configured the same, using the default
argument.
m = ConcreteModel()
m.b = MyBlock([0,1,2,3,4], default={"xinit":1, "yinit":2})
The next example uses the initialize
argument to override the configuration of
the first block. Initialize is a dictionary of dictionaries where the key of the
top level dictionary is the block index and the second level dictionary is
arguments for the config block.
m = ConcreteModel()
m.b = MyBlock([0,1,2,3,4], default={"xinit":1, "yinit":2},
initialize={0:{"xinit":1, "yinit":2}})
The next example shows a more complicated configuration where there are three
configurations, one for the first block, one for the last block, and one for the
interior blocks. This is accomplished by providing the idx_map
argument to
MyBlock, which is a function that maps a block index to a index in the initialize
dictionary. In this case 0 is mapped to 0, 4 is mapped to 4, and all elements
between 0 and 4 are mapped to 1. A lambda function is used to convert the block
index to the correct index in initialize.
m = ConcreteModel()
m.b = MyBlock(
[0,1,2,3,4],
idx_map = lambda i: 1 if i > 0 and i < 4 else i,
initialize={0:{"xinit":2001, "yinit":2002},
1:{"xinit":5001, "yinit":5002},
4:{"xinit":7001, "yinit":7002}})
The build methodÂ¶
The core part of any IDAES Block is the build method, which contains the instructions on how to construct the variables, constraints and other components that make up the model. The build method serves as the default rule for constructing an instance of an IDAES Block, and is triggered automatically whenever an instance of an IDAES Block is created unless a custom rule is provided by the user.
ProcessBlock ClassÂ¶

idaes.core.process_block.
declare_process_block_class
(name, block_class=<class 'idaes.core.process_block.ProcessBlock'>, doc='')[source]Â¶ Declare a new ProcessBlock subclass.
This is a decorator function for a class definition, where the class is derived from Pyomoâ€™s _BlockData. It creates a ProcessBlock subclass to contain the decorated class. The only requirment is that the subclass of _BlockData contain a build() method. The purpose of this decorator is to simplify subclassing Pyomoâ€™s block class.
Parameters:  name â€“ name of class to create
 block_class â€“ ProcessBlock or a subclass of ProcessBlock, this allows you to use a subclass of ProcessBlock if needed. The typical use case for Subclassing ProcessBlock is to impliment methods that operate on elements of an indexed block.
 doc â€“ Documentation for the class. This should play nice with sphinx.
Returns: Decorator function

class
idaes.core.process_block.
ProcessBlock
(*args, **kwargs)[source]Â¶ ProcessBlock is a Pyomo Block that is part of a system to make Pyomo Block easier to subclass. The main difference between a Pyomo Block and ProcessBlock from the user perspective is that a ProcessBlock has a rule assigned by default that calls the build() method for the contained ProcessBlockData objects. The default rule can be overridden, but the new rule should always call build() for the ProcessBlockData object.
Parameters:  rule (function) â€“ A rule function or None. Default rule calls build().
 concrete (bool) â€“ If True, make this a toplevel model. Default  False.
 ctype (str) â€“ Pyomo ctype of the block. Default  â€śBlockâ€ť
 default (dict) â€“ Default ProcessBlockData config
 initialize (dict) â€“ ProcessBlockData config for individual elements. Keys are BlockData indexes and values are dictionaries described under the â€śdefaultâ€ť argument above.
 idx_map (function) â€“ Function to take the index of a BlockData element and return the index in the initialize dict from which to read arguments. This can be provided to overide the default behavior of matching the BlockData index exactly to the index in initialize.
Returns: (ProcessBlock) New instance

class
idaes.core.process_base.
ProcessBlockData
(component)[source]Â¶ Base class for most IDAES process models and classes.
The primary purpose of this class is to create the local config block to handle arguments provided by the user when constructing an object and to ensure that these arguments are stored in the config block.
Additionally, this class contains a number of methods common to all IDAES classes.

build
()[source]Â¶ The build method is called by the default ProcessBlock rule. If a rule is sepecified other than the default it is important to call ProcessBlockDataâ€™s build method to put information from the â€śdefaultâ€ť and â€śinitializeâ€ť arguments to a ProcessBlock derived class into the BlockData objectâ€™s ConfigBlock.
The the build method should usually be overloaded in a subclass derived from ProcessBlockData. This method would generally add Pyomo components such as variables, expressions, and constraints to the object. It is important for build() methods implimented in derived classes to call build() from the super class.
Parameters: None â€“ Returns: None

fix_initial_conditions
(state='steadystate')[source]Â¶ This method fixes the initial conditions for dynamic models.
Parameters: state â€“ initial state to use for simulation (default = â€steadystateâ€™)  Returns :
 None

IDAES Modeling ConceptsÂ¶
Contents
IntroductionÂ¶
The purpose of this section of the documentation is to explain the different parts of the IDAES modeling framework, and what components belong in each part for the hierarchy. Each component is described in greater detail later in the documentation, however this section provides a general introduction to different types of components.
Time DomainÂ¶
Before starting on the different types of models present in the IDAES framework, it is important to discuss how time is handled by the framework. When a user first declares a Flowsheet model a time domain is created, the form of which depends on whether the Flowsheet is declared to be dynamic or steadystate (see FlowsheetBlock documentation). In situations where the user makes use of nested flowsheets, each subflowsheet refers to its parent flowsheet for the time domain.
Different models may handle the time domain differently, but in general all IDAES models refer to the time domain of their parent flowsheet. The only exception to this are blocks associated with Property calculations. PropertyBlocks represent the state of the material at a single point in space and time, and thus do not contain the time domain. Instead, PropertyBlocks are indexed by time (and space where applicable)  i.e. there is a separate PropertyBlock for each point in time. The user should keep this in mind when working with IDAES models, as it is important for understanding where the time index appears within a model.
In order to facilitate referencing of the time domain, all Flowsheet objects have a time configuration argument which is a reference to the time domain for that flowsheet. All IDAES models contain a flowsheet method which returns the parent flowsheet object, thus a reference to the time domain can always be found using the following code: flowsheet().config.time.
Another important thing to note is that steadystate models do contain a time domain, however this is generally a single point at time = 0.0. However, models still contain a reference to the time domain, and any components are still indexed by time even in a steadystate model (e.g. PropertyBlocks).
FlowsheetsÂ¶
The top level of the IDAES modeling framework is the Flowsheet model. Flowsheet models represent traditional process flowsheets, containing a number of Unit models representing process unit operations connected together into a flow network. Flowsheets generally contain three types of components:
 Unit models, representing unit operations,
 Arcs, representing connections between Unit models, and,
 Property Parameter blocks, representing the parameters associated with different materials present within the flowsheet.
Flowsheet models may also contain additional constraints relating to how different Unit models behave and interact, such as control and operational constraints. Generally speaking, if a Constraint is purely internal to a single unit, and does not depend on information from other units in the flowsheet, then the Constraint should be placed inside the relevant Unit model. Otherwise, the Constraint should be placed at the Flowsheet level.
Unit ModelsÂ¶
Unit models generally represent individual pieces of equipment present within a process which perform a specific task. Unit models in turn are generally composed of two main types of components:
 Control Volume Blocks, which represent volume of material over which we wish to perform material, energy and/or momentum balances, and,
 StateBlocks and ReactionBlocks, which represent the thermophysical, transport and reaction properties of the material at a specific point in space and time.
 Inlets and Outlets, which allow Unit models to connect to other Unit models.
Unit models will also contain Constraints describing the performance of the unit, which will relate terms in the balance equations to different phenomena.
A key feature of the IDAES modeling framework is the use of Control Volume Blocks. As mentioned above, Control Volumes represent a volume of material over which material, energy and/or momentum balances can be performed. Control Volume Blocks contain methods to automate the task of writing common forms of these balance equations. Control Volume Blocks can also automate the creation of StateBlocks and ReactionBlocks associated with the control volume.
Property blocks represent the state of a material at a given point in space and time within the process flowsheet, and contain the state variables, thermophysical, transport and reaction properties of a material (which are functions solely of the local state of the material). Within the IDAES process modeling framework, properties are divided into two types:
 Physical properties (StateBlocks), including thermophysical and transport properties, and
 Reaction properties (ReactionBlocks), which include all properties associated with chemical reactions.
Additionally, StateBlocks contain information on the extensive flow of material at that point in space and time, which is a departure from how engineers generally think about properties. This is required to facilitate the flexible formulation of the IDAES Framework by allowing the property package to dictate what form the balance equations will take, which requires the StateBlock to know the extensive flow information.
The calculations involved in property blocks of both types generally require a set of parameters which are constant across all instances of that type of property block. Rather than each property block containing its own copy of each of these parameters (thus duplicating parameters between blocks), each type of property block is associated with a Property Parameter Block (PhysicalParameterBlock or ReactionParameterBlock). Property Parameter Blocks serve as a centralized location for the constant parameters involved in property calculations, and all property blocks of the associated type link to the parameters contained in the parameter block.
Component ReferencesÂ¶
There are many situations in the IDAES modeling framework where a developer may want to make use of a modeling component (e.g. a variable or parameter) from one Block in another Block. The time domain is a good example of this  almost all Blocks within an IDAES model need to make use of the time domain, however the time domain exists only at the top level of the flowsheet structure. In order to make use of the time domain in other parts of the framework, references to the time domain are used instead. By convention, all references within the IDAES modeling framework are indicated by the suffix â€ś_refâ€ť attached to the name of the reference. E.g. all references to the time domain within the framework are called â€śtime_refâ€ť.
What Belongs in Each Type of Block?Â¶
A common question with the hierarchical structure of the IDAES framework is where does a specific variable or constraint belong (or conversely, where can I find a specific variable or constraint). In general, variables and constraints are divided based on the following guidelines:
Property Parameter Blocks  any parameter or quantity that is consistent across all instances of a Property Block belongs in the Property Parameter Block. This includes:
 component lists,
 lists of valid phases,
 universal constants (e.g. R, \(\pi\)),
 constants used in calculating properties (e.g. coefficients for calculating \(c_p\),
 reference states (e.g. \(P_{ref}\) and \(T_{ref}\)),
 lists of reaction identifiers,
 reaction stoichiometry.
Property Blocks  all state variables (including extensive flow information) and any quantity that is a function only of state variables plus the constraints required to calculate these. These include:
 flow rates (can be of different forms, e.g. mass or molar flow, on a total or component basis),
 temperature,
 pressure,
 intensive and extensive state functions (e.g. enthalpy); both variables and constraints.
Control Volume Blocks  material, energy and momentum balances and the associated terms. These include:
 balance equations,
 holdup volume,
 material and energy holdups; both variables and constraints,
 material and energy accumulation terms (Pyomo.dae handles the creation of the associated derivative constraints),
 material generation terms (kinetic reactions, chemical and phase equilibrium, mass transfer),
 extent of reaction terms and constraints relating these to the equivalent generation terms,
 phase fraction within the holdup volume and constrain on the sum of phase fractions,
 heat and work transfer terms,
 pressure change term
 diffusion and conduction terms (where applicable) and associated constraints,
 Mixer and Splitter blocks for handling multiple inlets/outlets.
Unit Model  any unit performance constraints and associated variables, such as:
 constraints relating balance terms to physical phenomena or properties (e.g. relating extent of reaction to reaction rate and volume),
 constraints describing flow of material into or out of unit (e.g. pressure driven flow constraints),
 unit level efficiency constraints (e.g. relating mechanical work to fluid work).
Flowsheet Model  any constraints related to interaction of unit models and associated variables. Examples include:
 control constraints relating behavior between different units (e.g. a constraint on valve opening based on the level in another unit).
Flowsheet Model ClassÂ¶
Contents
Flowsheet models make up the top level of the IDAES modeling framework, and represent the flow of material and energy through a process. Flowsheets will generally contain a number of UnitModels to represent unit operations within the process, and will contain one or more Property Packages which represent the thermophysical and transport properties of material within the process.
Flowsheet models are responsible for establishing and maintaining the time domain of the model, including declaring whether the process model will be dynamic or steadystate. This time domain is passed on to all models attached to the flowsheet (such as Unit Models and subFlowsheets). The Flowsheet model also serves as a centralized location for organizing property packages, and can set one property package to use as a default throughout the flowsheet.
Flowsheet Blocks may contain other Flowsheet Blocks in order to create nested flowsheets and to better organize large, complex process configurations. In these cases, the toplevel Flowsheet Block creates the time domain, and each subflowsheet creates a reference this time domain. Subflowsheets may make use of any property package declared at a higher level, or declare new property package for use within itself  any of these may be set as the default property package for a subFlowsheet.
Default Property PackagesÂ¶
Flowsheet Blocks may assign a property package to use as a default for all UnitModels within the Flowsheet. If a specific property package is not provided as an argument when constructing a UnitModel, the UnitModel will search up the model tree until it finds a default property package declared. The UnitModel will use the first default property package it finds during the search, and will return an error if no default is found.
Flowsheet Configuration ArgumentsÂ¶
Flowsheet blocks have three configuration arguments which are stored within a Config block (flowsheet.config). These arguments can be set by passing arguments when instantiating the class, and are described below:
 dynamic  indicates whether the flowsheet should be dynamic or steadystate. If dynamic = True, the flowsheet is declared to be a dynamic flowsheet, and the time domain will be a Pyomo ContunuousSet. If dynamic = False, the flowsheet is declared to be steadystate, and the time domain will be an ordered Pyomo Set. For top level Flowsheets, dynamic defaults to False if not provided. For lower level Flowsheets, the dynamic will take the same value as that of the parent model if not provided. It is possible to declare steadystate subFlowsheets as part of dynamic Flowsheets if desired, however the reverse is not true (cannot have dynamic Flowsheets within steadystate Flowsheets).
 time  a reference to the time domain for the flowsheet. During flowsheet creation, users may provide a Set or ContinuousSet that the flowsheet should use as the time domain. If not provided, then the flowsheet will look for a parent flowsheet and set this equal to the parentâ€™s time domain, otherwise a new time domain will be created and assigned here.
 time_set  used to initialize the time domain in toplevel Flowsheets. When constructing the time domain in toplevel Flowsheets, time_set is used to initialize the ContinuousSet or Set created. This can be used to set start and end times, and to establish points of interest in time (e.g. times when disturbances will occur). If dynamic = True, time_set defaults to [0.0, 1.0] if not provided, if dynamic = False time_set defaults to [0.0]. time_set is not used in subFlowsheets and will be ignored.
 default_property_package  can be used to assign the default property package for a Flowsheet. Defaults to None if not provided.
Flowsheet ClassesÂ¶

class
idaes.core.flowsheet_model.
FlowsheetBlockData
(component)[source]Â¶ The FlowsheetBlockData Class forms the base class for all IDAES process flowsheet models. The main purpose of this class is to automate the tasks common to all flowsheet models and ensure that the necessary attributes of a flowsheet model are present.
The most signfiicant role of the FlowsheetBlockData class is to automatically create the time domain for the flowsheet.

build
()[source]Â¶ General build method for FlowsheetBlockData. This method calls a number of submethods which automate the construction of expected attributes of flowsheets.
Inheriting models should call super().build.
Parameters: None â€“ Returns: None

is_flowsheet
()[source]Â¶ Method which returns True to indicate that this component is a flowsheet.
Parameters: None â€“ Returns: True

model_check
()[source]Â¶ This method runs model checks on all unit models in a flowsheet.
This method searches for objects which inherit from UnitModelBlockData and executes the model_check method if it exists.
Parameters: None â€“ Returns: None

serialize
(file_base_name, overwrite=False)[source]Â¶ Serializes the flowsheet and saves it to a file that can be read by the idaesmodelvis jupyter lab extension.
Parameters: file_base_name â€“ The file prefix to the .idaes.vis file produced. The file is created/saved in the directory that you ran from Jupyter Lab. :param overwrite: Boolean to overwrite an existing file_base_name.idaes.vis. If True, the existing file with the same file_base_name will be overwritten. This will cause you to lose any saved layout. If False and there is an existing file with that file_base_name, you will get an error message stating that you cannot save a file to the file_base_name (and therefore overwriting the saved layout). If there is not an existing file with that file_base_name then it saves as normal. Defaults to False. :return: None

stream_table
(true_state=False, time_point=0, orient='columns')[source]Â¶ Method to generate a stream table by iterating over all Arcs in the flowsheet.
Parameters:  true_state â€“ whether the state variables (True) or display variables (False, default) from the StateBlocks should be used in the stream table.
 time_point â€“ point in the time domain at which to create stream table (default = 0)
 orient â€“ whether stream should be shown by columns (â€ścolumnsâ€ť) or rows (â€śindexâ€ť)
Returns: A pandas dataframe containing stream table information


class
idaes.core.flowsheet_model.
FlowsheetBlock
(*args, **kwargs)Â¶ FlowsheetBlock is a specialized Pyomo block for IDAES flowsheet models, and contains instances of FlowsheetBlockData.
Parameters:  rule (function) â€“ A rule function or None. Default rule calls build().
 concrete (bool) â€“ If True, make this a toplevel model. Default  False.
 ctype (str) â€“ Pyomo ctype of the block. Default  â€śBlockâ€ť
 default (dict) â€“
Default ProcessBlockData config
 Keys
 dynamic
 Indicates whether this model will be dynamic, default  useDefault. Valid values: { useDefault  get flag from parent or False, True  set as a dynamic model, False  set as a steadystate model.}
 time
 Pointer to the time domain for the flowsheet. Users may provide an existing time domain from another flowsheet, otherwise the flowsheet will search for a parent with a time domain or create a new time domain and reference it here.
 time_set
 Set of points for initializing time domain. This should be a list of floating point numbers, default  [0].
 default_property_package
 Indicates the default property package to be used by models within this flowsheet if not otherwise specified, default  None. Valid values: { None  no default property package, a ParameterBlock object.}
 initialize (dict) â€“ ProcessBlockData config for individual elements. Keys are BlockData indexes and values are dictionaries described under the â€śdefaultâ€ť argument above.
 idx_map (function) â€“ Function to take the index of a BlockData element and return the index in the initialize dict from which to read arguments. This can be provided to overide the default behavior of matching the BlockData index exactly to the index in initialize.
Returns: (FlowsheetBlock) New instance
Property PackagesÂ¶
Physical Property Package ClassesÂ¶
Physical property packages represent a collection of calculations necessary to determine the state properties of a given material. Property calculations form a critical part of any process model, and thus property packages form the core of the IDAES modeling framework.
Physical property packages consist of two parts:
 PhysicalParameterBlocks, which contain a set of parameters associated with the specific material(s) being modeled, and
 StateBlocks, which contain the actual calculations of the state variables and functions.
Physical Parameter blocks serve as a central location for linking to a property package, and contain all the parameters and indexing sets used by a given property package.
The role of the PhysicalParameterBlock class is to set up the references required by the rest of the IDAES framework for constructing instances of StateBlocks and attaching these to the PhysicalParameter block for ease of use. This allows other models to be pointed to the PhysicalParameter block in order to collect the necessary information and to construct the necessary StateBlocks without the need for the user to do this manually.
Physical property packages form the core of any process model in the IDAES modeling framework, and are used by all of the other modeling components to inform them of what needs to be constructed. In order to do this, the IDAES modeling framework looks for a number of attributes in the PhysicalParameter block which are used to inform the construction of other components.
 state_block_class  a pointer to the associated class that should be called when constructing StateBlocks.
 phase_list  a Pyomo Set object defining the valid phases of the mixture of interest.
 component_list  a Pyomo Set defining the names of the chemical species present in the mixture.
 element_list  (optional) a Pyomo Set defining the names of the chemical elements that make up the species within the mixture. This is used when doing elemental material balances.
 element_comp  (optional) a dictlike object which defines the elemental composition of each species in component_list. Form: component: {element_1: value, element_2: value, â€¦}.
 supported properties metadata  a list of supported physical properties that the property package supports, along with instruction to the framework on how to construct the associated variables and constraints, and the units of measurement used for the property. This information is set using the add_properties attribute of the define_metadata class method.
Physical Parameter blocks have one standard configuration argument:
 default_arguments  this allows the user to provide a set of default values for construction arguments in associated StateBlocks, which will be passed to all StateBlocks when they are constructed.

class
idaes.core.property_base.
PhysicalParameterBlock
(component)[source]Â¶ This is the base class for thermophysical parameter blocks. These are blocks that contain a set of parameters associated with a specific thermophysical property package, and are linked to by all instances of that property package.
State Blocks are used within all IDAES Unit models (generally within ControlVolume Blocks) in order to calculate physical properties given the state of the material. State Blocks are notably different to other types of Blocks within IDAES as they are always indexed by time (and possibly space as well). There are two base Classes associated with State Blocks:
 StateBlockData forms the base class for all StateBlockData objects, which contain the instructions on how to construct each instance of a State Block.
 StateBlock is used for building classes which contain methods to be applied to sets of Indexed State Blocks (or to a subset of these). See the documentation on declare_process_block_class and the IDAES tutorials and examples for more information.
State Blocks have the following construction arguments:
 parameters  a reference to the associated Physical Parameter block which will be used to make references to all necessary parameters.
 defined_state  this argument indicates whether the State Block should expect the material state to be fully defined by another part of the flowsheet (such as by an upstream unit operation). This argument is used to determine whether constraints such as sums of mole fractions should be enforced.
 has_phase_equilibrium  indicates whether the associated Control Volume or Unit model expects phase equilibrium to be enforced (if applicable).
StateBlockData contains the code necessary for implementing the as needed construction of variables and constraints.

class
idaes.core.property_base.
StateBlockData
(component)[source]Â¶ This is the base class for state block data objects. These are blocks that contain the Pyomo components associated with calculating a set of thermophysical and transport properties for a given material.

calculate_bubble_point_pressure
(*args, **kwargs)[source]Â¶ Method which computes the bubble point pressure for a multi component mixture given a temperature and mole fraction.

calculate_bubble_point_temperature
(*args, **kwargs)[source]Â¶ Method which computes the bubble point temperature for a multi component mixture given a pressure and mole fraction.

calculate_dew_point_pressure
(*args, **kwargs)[source]Â¶ Method which computes the dew point pressure for a multi component mixture given a temperature and mole fraction.

calculate_dew_point_temperature
(*args, **kwargs)[source]Â¶ Method which computes the dew point temperature for a multi component mixture given a pressure and mole fraction.

define_display_vars
()[source]Â¶ Method used to specify components to use to generate stream tables and other outputs. Defaults to define_state_vars, and developers should overload as required.

define_port_members
()[source]Â¶ Method used to specify components to populate Ports with. Defaults to define_state_vars, and developers should overload as required.

define_state_vars
()[source]Â¶ Method that returns a dictionary of state variables used in property package. Implement a placeholder method which returns an Exception to force users to overload this.

get_energy_density_terms
(*args, **kwargs)[source]Â¶ Method which returns a valid expression for enthalpy density to use in the energy balances.

get_energy_diffusion_terms
(*args, **kwargs)[source]Â¶ Method which returns a valid expression for energy diffusion to use in the energy balances.

get_enthalpy_flow_terms
(*args, **kwargs)[source]Â¶ Method which returns a valid expression for enthalpy flow to use in the energy balances.

get_material_density_terms
(*args, **kwargs)[source]Â¶ Method which returns a valid expression for material density to use in the material balances .

get_material_diffusion_terms
(*args, **kwargs)[source]Â¶ Method which returns a valid expression for material diffusion to use in the material balances.


class
idaes.core.property_base.
StateBlock
(*args, **kwargs)[source]Â¶ This is the base class for state block objects. These are used when constructing the SimpleBlock or IndexedBlock which will contain the PropertyData objects, and contains methods that can be applied to multiple StateBlockData objects simultaneously.

initialize
(*args, **kwargs)[source]Â¶ This is a default initialization routine for StateBlocks to ensure that a routine is present. All StateBlockData classes should overload this method with one suited to the particular property package
Parameters: None â€“ Returns: None

report
(index=0, true_state=False, dof=False, ostream=None, prefix='')[source]Â¶ Default report method for StateBlocks. Returns a Block report populated with either the display or state variables defined in the StateBlockData class.
Parameters:  index â€“ tuple of Block indices indicating which point in time (and space if applicable) to report state at.
 true_state â€“ whether to report the display variables (False default) or the actual state variables (True)
 dof â€“ whether to show local degrees of freedom in the report (default=False)
 ostream â€“ output stream to write report to
 prefix â€“ string to append to the beginning of all output lines
Returns: Printed output to ostream

Reaction Property Package ClassesÂ¶
Reaction property packages represent a collection of calculations necessary to determine the reaction behavior of a mixture at a given state. Reaction properties depend upon the state and physical properties of the material, and thus must be linked to a StateBlock which provides the necessary state and physical property information.
Reaction property packages consist of two parts:
 ReactionParameterBlocks, which contain a set of parameters associated with the specific reaction(s) being modeled, and
 ReactionBlocks, which contain the actual calculations of the reaction behavior.
Reaction Parameter blocks serve as a central location for linking to a reaction property package, and contain all the parameters and indexing sets used by a given reaction package.
The role of the ReactionParameterBlock class is to set up the references required by the rest of the IDAES framework for constructing instances of ReactionBlocks and attaching these to the ReactionParameter block for ease of use. This allows other models to be pointed to the ReactionParameter block in order to collect the necessary information and to construct the necessary ReactionBlocks without the need for the user to do this manually.
Reaction property packages are used by all of the other modeling components to inform them of what needs to be constructed when dealing with chemical reactions. In order to do this, the IDAES modeling framework looks for a number of attributes in the ReactionParameter block which are used to inform the construction of other components.
 reaction_block_class  a pointer to the associated class that should be called when constructing ReactionBlocks.
 phase_list  a Pyomo Set object defining the valid phases of the mixture of interest.
 component_list  a Pyomo Set defining the names of the chemical species present in the mixture.
 rate_reaction_idx  a Pyomo Set defining a list of names for the kinetically controlled reactions of interest.
 rate_reaction_stoichiometry  a dictlike object defining the stoichiometry of the kinetically controlled reactions. Keys should be tuples of (rate_reaction_idx, phase_list, component_list) and values equal to the stoichiometric coefficient for that index.
 equilibrium_reaction_idx  a Pyomo Set defining a list of names for the equilibrium controlled reactions of interest.
 equilibrium_reaction_stoichiometry  a dictlike object defining the stoichiometry of the equilibrium controlled reactions. Keys should be tuples of (equilibrium_reaction_idx, phase_list, component_list) and values equal to the stoichiometric coefficient for that index.
 supported properties metadata  a list of supported reaction properties that the property package supports, along with instruction to the framework on how to construct the associated variables and constraints, and the units of measurement used for the property. This information is set using the add_properties attribute of the define_metadata class method.
 required properties metadata  a list of physical properties that the reaction property calculations depend upon, and must be supported by the associated StateBlock. This information is set using the add_required_properties attribute of the define_metadata class method.
Reaction Parameter blocks have two standard configuration arguments:
 property_package  a pointer to a PhysicalParameterBlock which will be used to construct the StateBlocks to which associated ReactionBlocks will be linked. Reaction property packages must be tied to a single Physical property package, and this is used to validate the connections made later when constructing ReactionBlocks.
 default_arguments  this allows the user to provide a set of default values for construction arguments in associated ReactionBlocks, which will be passed to all ReactionBlocks when they are constructed.
Reaction Blocks are used within IDAES Unit models (generally within ControlVolume Blocks) in order to calculate reaction properties given the state of the material (provided by an associated StateBlock). Reaction Blocks are notably different to other types of Blocks within IDAES as they are always indexed by time (and possibly space as well), and are also not fully self contained (in that they depend upon the associated state block for certain variables). There are two bases Classes associated with Reaction Blocks:
 ReactionBlockDataBase forms the base class for all ReactionBlockData objects, which contain the instructions on how to construct each instance of a Reaction Block.
 ReactionBlockBase is used for building classes which contain methods to be applied to sets of Indexed Reaction Blocks (or to a subset of these). See the documentation on declare_process_block_class and the IDAES tutorials and examples for more information.
Reaction Blocks have the following construction arguments:
 parameters  a reference to the associated Reaction Parameter block which will be used to make references to all necessary parameters.
 state_block  a reference to the associated StateBlock which will provide the necessary state and physical property information.
 has_equilibrium  indicates whether the associated Control Volume or Unit model expects chemical equilibrium to be enforced (if applicable).
ReactionBlockDataBase contains the code necessary for implementing the as needed construction of variables and constraints.

class
idaes.core.reaction_base.
ReactionBlockDataBase
(component)[source]Â¶ This is the base class for reaction block data objects. These are blocks that contain the Pyomo components associated with calculating a set of reacion properties for a given material.

class
idaes.core.reaction_base.
ReactionBlockBase
(*args, **kwargs)[source]Â¶ This is the base class for reaction block objects. These are used when constructing the SimpleBlock or IndexedBlock which will contain the PropertyData objects, and contains methods that can be applied to multiple ReactionBlockData objects simultaneously.
IDAES Property PackagesÂ¶
The IDAES process modeling framework divides property calculations into two parts;
 physical and transport properties
 chemical reaction properties
Defining the calculations to be used when calculating properties is done via â€śproperty packagesâ€ť, which contain a set of related calculations for a number of properties of interest. Property packages may be general in purpose, such as ideal gas equations, or specific to a certain application.
As Needed PropertiesÂ¶
Process flow sheets often require a large number of properties to be calculate, but not all of these are required in every unit operation. Calculating additional properties that are not required is undesirable, as it leads to larger problem sizes and unnecessary complexity of the resulting model.
To address this, the IDAES modeling framework supports â€śas neededâ€ť construction of properties, where the variables and constraints required to calculate a given quantity are not added to a model unless the model calls for this quantity. To designate a property as an â€śas neededâ€ť quantity, a method can be declared in the associated property BlockData class (StateBlockData or ReactionBlockData) which contains the instructions for constructing the variables and constraints associated with the quantity (rather than declaring these within the BlockDataâ€™s build method). The name of this method can then be associated with the property via the add_properties metadata in the property packages ParameterBlock, which indicates to the framework that when this property is called for, the associated method should be run.
The add_properties metadata can also indicate that a property should always be present (i.e. constructed in the BlockDataâ€™s build method) by setting the method to None, or that it is not supported by setting the method to False.
Unit Model ClassÂ¶
The UnitModelBlock is class is designed to form the basis of all IDAES Unit Models, and contains a number of methods which are common to all Unit Models.
UnitModelBlock Construction ArgumentsÂ¶
The UnitModelBlock class by default has only one construction argument, which is listed below. However, most models inheriting from UnitModelBlock should declare their own set of configuration arguments which contain more information on how the model should be constructed.
 dynamic  indicates whether the Unit model should be dynamic or steadystate, and if dynamic = True, the unit is declared to be a dynamic model. dynamic defaults to useDefault if not provided when instantiating the Unit model (see below for more details). It is possible to declare steadystate Unit models as part of dynamic Flowsheets if desired, however the reverse is not true (cannot have dynamic Unit models within steadystate Flowsheets).
Collecting Time DomainÂ¶
The next task of the UnitModelBlock class is to establish the time domain for the unit by collecting the necessary information from the parent Flowsheet model. If the dynamic construction argument is set to useDefault then the Unit model looks to its parent model for the dynamic argument, otherwise the value provided at construction is used.
Finally, if the Unit model has a construction argument named â€śhas_holdupâ€ť (not part of the base class), then this is checked to ensure that if dynamic = True then has_holdup is also True. If this check fails then a ConfigurationError exception will be thrown.
Modeling Support MethodsÂ¶
The UnitModelBlock class also contains a number of methods designed to facilitate the construction of common components of a model, and these are described below.
All (or almost all) Unit Models will have inlets and outlets which allow material to flow in and out of the unit being modeled. In order to save the model developer from having to write the code for each inlet themselves, UnitModelBlock contains a method named build_inlet_port which can automatically create an inlet to a specified ControlVolume block (or linked to a specified StateBlock). The build_inlet_port method is described in more detail in the documentation below.
Similar to build_inlet_port, UnitModelBlock also has a method named build_outlet_port for constructing outlets from Unit models. The build_outlets method is described in more detail in the documentation below.
In order to support the IDAES Model Check tools, UnitModelBlock contains a simple model_check method which assumes a single Holdup block and calls the model_check method on this block. Model developers are encouraged to create their own model_check methods for their particular applications.
All Unit Models need to have an initialization routine, which should be customized for each Unit model, In order to ensure that all Unit models have at least a basic initialization routine, UnitModelBlock contains a generic initialization procedure which may be sufficient for simple models with only one Holdup Block. Model developers are strongly encouraged to write their own initialization routines rather than relying on the default method.
UnitModelBlock ClassesÂ¶

class
idaes.core.unit_model.
UnitModelBlockData
(component)[source]Â¶ This is the class for process unit operations models. These are models that would generally appear in a process flowsheet or superstructure.

add_inlet_port
(name=None, block=None, doc=None)[source]Â¶ This is a method to build inlet Port objects in a unit model and connect these to a specified control volume or state block.
The name and block arguments are optional, but must be used together. i.e. either both arguments are provided or neither.
Keyword Arguments:  = name to use for Port object (name) â€“
 = an instance of a ControlVolume or StateBlock to use as the (block) â€“ source to populate the Port object. If a ControlVolume is provided, the method will use the inlet state block as defined by the ControlVolume. If not provided, method will attempt to default to an object named control_volume.
 = doc string for Port object (doc) â€“
Returns: A Pyomo Port object and associated components.

add_outlet_port
(name=None, block=None, doc=None)[source]Â¶ This is a method to build outlet Port objects in a unit model and connect these to a specified control volume or state block.
The name and block arguments are optional, but must be used together. i.e. either both arguments are provided or neither.
Keyword Arguments:  = name to use for Port object (name) â€“
 = an instance of a ControlVolume or StateBlock to use as the (block) â€“ source to populate the Port object. If a ControlVolume is provided, the method will use the outlet state block as defined by the ControlVolume. If not provided, method will attempt to default to an object named control_volume.
 = doc string for Port object (doc) â€“
Returns: A Pyomo Port object and associated components.

add_port
(name=None, block=None, doc=None)[source]Â¶ This is a method to build Port objects in a unit model and connect these to a specified StateBlock. :keyword name = name to use for Port object.: :keyword block = an instance of a StateBlock to use as the source to: populate the Port object :keyword doc = doc string for Port object:
Returns: A Pyomo Port object and associated components.

build
()[source]Â¶ General build method for UnitModelBlockData. This method calls a number of submethods which automate the construction of expected attributes of unit models.
Inheriting models should call super().build.
Parameters: None â€“ Returns: None

initialize
(state_args=None, outlvl=0, solver='ipopt', optarg={'tol': 1e06})[source]Â¶ This is a general purpose initialization routine for simple unit models. This method assumes a single ControlVolume block called controlVolume, and first initializes this and then attempts to solve the entire unit.
More complex models should overload this method with their own initialization routines,
Keyword Arguments:  state_args â€“ a dict of arguments to be passed to the property package(s) to provide an initial state for initialization (see documentation of the specific property package) (default = {}).
 outlvl â€“
sets output level of initialisation routine
 0 = no output (default)
 1 = return solver state for each step in routine
 2 = return solver state for each step in subroutines
 3 = include solver output infomation (tee=True)
 optarg â€“ solver options dictionary object (default={â€tolâ€™: 1e6})
 solver â€“ str indicating which solver to use during initialization (default = â€ipoptâ€™)
Returns: None

model_check
()[source]Â¶ This is a general purpose initialization routine for simple unit models. This method assumes a single ControlVolume block called controlVolume and tries to call the model_check method of the controlVolume block. If an AttributeError is raised, the check is passed.
More complex models should overload this method with a model_check suited to the particular application, especially if there are multiple ControlVolume blocks present.
Parameters: None â€“ Returns: None


class
idaes.core.unit_model.
UnitModelBlock
(*args, **kwargs)Â¶ Parameters:  rule (function) â€“ A rule function or None. Default rule calls build().
 concrete (bool) â€“ If True, make this a toplevel model. Default  False.
 ctype (str) â€“ Pyomo ctype of the block. Default  â€śBlockâ€ť
 default (dict) â€“
Default ProcessBlockData config
 Keys
 dynamic
 Indicates whether this model will be dynamic or not, default = useDefault. Valid values: { useDefault  get flag from parent (default = False), True  set as a dynamic model, False  set as a steadystate model.}
 has_holdup
 Indicates whether holdup terms should be constructed or not. Must be True if dynamic = True, default  False. Valid values: { True  construct holdup terms, False  do not construct holdup terms}
 initialize (dict) â€“ ProcessBlockData config for individual elements. Keys are BlockData indexes and values are dictionaries described under the â€śdefaultâ€ť argument above.
 idx_map (function) â€“ Function to take the index of a BlockData element and return the index in the initialize dict from which to read arguments. This can be provided to overide the default behavior of matching the BlockData index exactly to the index in initialize.
Returns: (UnitModelBlock) New instance
Control Volume ClassesÂ¶
0D Control Volume ClassÂ¶
The ControlVolume0DBlock block is the most commonly used Control Volume class, and is used for systems where there is a wellmixed volume of fluid, or where variations in spatial domains are considered to be negligible. ControlVolume0DBlock blocks generally contain two StateBlocks  one for the incoming material and one for the material within and leaving the volume  and one StateBlocks.

class
idaes.core.control_volume0d.
ControlVolume0DBlock
(*args, **kwargs)Â¶ ControlVolume0DBlock is a specialized Pyomo block for IDAES nondiscretized control volume blocks, and contains instances of ControlVolume0DBlockData.
ControlVolume0DBlock should be used for any control volume with a defined volume and distinct inlets and outlets which does not require spatial discretization. This encompases most basic unit models used in process modeling.
Parameters:  rule (function) â€“ A rule function or None. Default rule calls build().
 concrete (bool) â€“ If True, make this a toplevel model. Default  False.
 ctype (str) â€“ Pyomo ctype of the block. Default  â€śBlockâ€ť
 default (dict) â€“
Default ProcessBlockData config
 Keys
 dynamic
 Indicates whether this model will be dynamic, default  useDefault. Valid values: { useDefault  get flag from parent, True  set as a dynamic model, False  set as a steadystate model}
 has_holdup
 Indicates whether holdup terms should be constructed or not. Must be True if dynamic = True, default  False. Valid values: { True  construct holdup terms, False  do not construct holdup terms}
 property_package
 Property parameter object used to define property calculations, default  useDefault. Valid values: { useDefault  use default package from parent model or flowsheet, PropertyParameterObject  a PropertyParameterBlock object.}
 property_package_args
 A ConfigBlock with arguments to be passed to a property block(s) and used when constructing these, default  None. Valid values: { see property package for documentation.}
 reaction_package
 Reaction parameter object used to define reaction calculations, default  None. Valid values: { None  no reaction package, ReactionParameterBlock  a ReactionParameterBlock object.}
 reaction_package_args
 A ConfigBlock with arguments to be passed to a reaction block(s) and used when constructing these, default  None. Valid values: { see reaction package for documentation.}
 auto_construct
 If set to True, this argument will trigger the auto_construct method which will attempt to construct a set of material, energy and momentum balance equations based on the parent unitâ€™s config block. The parent unit must have a config block which derives from CONFIG_Base, default  False. Valid values: { True  use automatic construction, False  do not use automatic construciton.}
 initialize (dict) â€“ ProcessBlockData config for individual elements. Keys are BlockData indexes and values are dictionaries described under the â€śdefaultâ€ť argument above.
 idx_map (function) â€“ Function to take the index of a BlockData element and return the index in the initialize dict from which to read arguments. This can be provided to overide the default behavior of matching the BlockData index exactly to the index in initialize.
Returns: (ControlVolume0DBlock) New instance

class
idaes.core.control_volume0d.
ControlVolume0DBlockData
(component)[source]Â¶ 0Dimensional (NonDiscretised) ControlVolume Class
This class forms the core of all nondiscretized IDAES models. It provides methods to build property and reaction blocks, and add mass, energy and momentum balances. The form of the terms used in these constraints is specified in the chosen property package.

add_geometry
()[source]Â¶ Method to create volume Var in ControlVolume.
Parameters: None â€“ Returns: None

add_phase_component_balances
(has_rate_reactions=False, has_equilibrium_reactions=False, has_phase_equilibrium=False, has_mass_transfer=False, custom_molar_term=None, custom_mass_term=None)[source]Â¶ This method constructs a set of 0D material balances indexed by time, phase and component.
Parameters:  has_rate_reactions â€“ whether default generation terms for rate reactions should be included in material balances
 has_equilibrium_reactions â€“ whether generation terms should for chemical equilibrium reactions should be included in material balances
 has_phase_equilibrium â€“ whether generation terms should for phase equilibrium behaviour should be included in material balances
 has_mass_transfer â€“ whether generic mass transfer terms should be included in material balances
 custom_molar_term â€“ a Pyomo Expression representing custom terms to be included in material balances on a molar basis. Expression must be indexed by time, phase list and component list
 custom_mass_term â€“ a Pyomo Expression representing custom terms to be included in material balances on a mass basis. Expression must be indexed by time, phase list and component list
Returns: Constraint object representing material balances

add_phase_energy_balances
(*args, **kwargs)[source]Â¶ Method for adding energy balances (including kinetic energy) indexed by phase to the control volume.
See specific control volume documentation for details.

add_phase_enthalpy_balances
(*args, **kwargs)[source]Â¶ Method for adding enthalpy balances indexed by phase to the control volume.
See specific control volume documentation for details.

add_phase_momentum_balances
(*args, **kwargs)[source]Â¶ Method for adding momentum balances indexed by phase to the control volume.
See specific control volume documentation for details.

add_phase_pressure_balances
(*args, **kwargs)[source]Â¶ Method for adding pressure balances indexed by phase to the control volume.
See specific control volume documentation for details.

add_reaction_blocks
(has_equilibrium=None)[source]Â¶ This method constructs the reaction block for the control volume.
Parameters:  has_equilibrium â€“ indicates whether equilibrium calculations will be required in reaction block
 package_arguments â€“ dictlike object of arguments to be passed to reaction block as construction arguments
Returns: None

add_state_blocks
(information_flow=<FlowDirection.forward: 1>, has_phase_equilibrium=None)[source]Â¶ This method constructs the inlet and outlet state blocks for the control volume.
Parameters:  information_flow â€“ a FlowDirection Enum indicating whether information flows from inlettooutlet or outlettoinlet
 has_phase_equilibrium â€“ indicates whether equilibrium calculations will be required in state blocks
 package_arguments â€“ dictlike object of arguments to be passed to state blocks as construction arguments
Returns: None

add_total_component_balances
(has_rate_reactions=False, has_equilibrium_reactions=False, has_phase_equilibrium=False, has_mass_transfer=False, custom_molar_term=None, custom_mass_term=None)[source]Â¶ This method constructs a set of 0D material balances indexed by time and component.
Parameters:   whether default generation terms for rate (has_rate_reactions) â€“ reactions should be included in material balances
  whether generation terms should for (has_equilibrium_reactions) â€“ chemical equilibrium reactions should be included in material balances
  whether generation terms should for phase (has_phase_equilibrium) â€“ equilibrium behaviour should be included in material balances
  whether generic mass transfer terms should be (has_mass_transfer) â€“ included in material balances
  a Pyomo Expression representing custom terms to (custom_mass_term) â€“ be included in material balances on a molar basis. Expression must be indexed by time, phase list and component list
  a Pyomo Expression representing custom terms to â€“ be included in material balances on a mass basis. Expression must be indexed by time, phase list and component list
Returns: Constraint object representing material balances

add_total_element_balances
(has_rate_reactions=False, has_equilibrium_reactions=False, has_phase_equilibrium=False, has_mass_transfer=False, custom_elemental_term=None)[source]Â¶ This method constructs a set of 0D element balances indexed by time.
Parameters:   whether default generation terms for rate (has_rate_reactions) â€“ reactions should be included in material balances
  whether generation terms should for (has_equilibrium_reactions) â€“ chemical equilibrium reactions should be included in material balances
  whether generation terms should for phase (has_phase_equilibrium) â€“ equilibrium behaviour should be included in material balances
  whether generic mass transfer terms should be (has_mass_transfer) â€“ included in material balances
  a Pyomo Expression representing custom (custom_elemental_term) â€“ terms to be included in material balances on a molar elemental basis. Expression must be indexed by time and element list
Returns: Constraint object representing material balances

add_total_energy_balances
(*args, **kwargs)[source]Â¶ Method for adding a total energy balance (including kinetic energy) to the control volume.
See specific control volume documentation for details.

add_total_enthalpy_balances
(has_heat_of_reaction=False, has_heat_transfer=False, has_work_transfer=False, custom_term=None)[source]Â¶ This method constructs a set of 0D enthalpy balances indexed by time and phase.
Parameters:   whether terms for heat of reaction should (has_heat_of_reaction) â€“ be included in enthalpy balance
  whether terms for heat transfer should be (has_heat_transfer) â€“ included in enthalpy balances
  whether terms for work transfer should be (has_work_transfer) â€“ included in enthalpy balances
  a Pyomo Expression representing custom terms to (custom_term) â€“ be included in enthalpy balances. Expression must be indexed by time and phase list
Returns: Constraint object representing enthalpy balances

add_total_material_balances
(*args, **kwargs)[source]Â¶ Method for adding a total material balance to the control volume.
See specific control volume documentation for details.

add_total_momentum_balances
(*args, **kwargs)[source]Â¶ Method for adding a total momentum balance to the control volume.
See specific control volume documentation for details.

add_total_pressure_balances
(has_pressure_change=False, custom_term=None)[source]Â¶ This method constructs a set of 0D pressure balances indexed by time.
Parameters:   whether terms for pressure change should be (has_pressure_change) â€“ included in enthalpy balances
  a Pyomo Expression representing custom terms to (custom_term) â€“ be included in pressure balances. Expression must be indexed by time
Returns: Constraint object representing pressure balances

initialize
(state_args=None, outlvl=0, optarg=None, solver='ipopt', hold_state=True)[source]Â¶ Initialisation routine for 0D control volume (default solver ipopt)
Keyword Arguments:  state_args â€“ a dict of arguments to be passed to the property package(s) to provide an initial state for initialization (see documentation of the specific property package) (default = {}).
 outlvl â€“ sets output level of initialisation routine. Valid values: 0  no output (default), 1  return solver state for each step in routine, 2  include solver output infomation (tee=True)
 optarg â€“ solver options dictionary object (default=None)
 solver â€“ str indicating whcih solver to use during initialization (default = â€ipoptâ€™)
 hold_state â€“ flag indicating whether the initialization routine should unfix any state variables fixed during initialization, default  True. Valid values: True  states variables are not unfixed, and a dict of returned containing flags for which states were fixed during initialization, False  state variables are unfixed after initialization by calling the release_state method.
Returns: If hold_states is True, returns a dict containing flags for which states were fixed during initialization.

model_check
()[source]Â¶ This method executes the model_check methods on the associated state blocks (if they exist). This method is generally called by a unit model as part of the unitâ€™s model_check method.
Parameters: None â€“ Returns: None

release_state
(flags, outlvl=0)[source]Â¶ Method to release state variables fixed during initialisation.
Keyword Arguments:  flags â€“ dict containing information of which state variables were fixed during initialization, and should now be unfixed. This dict is returned by initialize if hold_state = True.
 outlvl â€“ sets output level of logging
Returns: None

This section documents the variables and constraints created by each of the methods provided by the ControlVolume0DBlock class.
 \(t\) indicates time index
 \(p\) indicates phase index
 \(j\) indicates component index
 \(e\) indicates element index
 \(r\) indicates reaction name index
The add_geometry method creates a single variable within the control volume named volume indexed by time (allowing for varying volume over time). A number of other methods depend on this variable being present, thus this method should generally be called first.
Variables
Variable Name  Symbol  Indices  Conditions 

volume  \(V_t\)  t  None 
Constraints
No additional constraints
Material balances are written for each component in each phase (e.g. separate balances for liquid water and steam). Physical property packages may include information to indicate that certain species do not appear in all phases, and material balances will not be written in these cases (if has_holdup is True holdup terms will still appear for these species, however these will be set to 0).
Variables
Variable Name  Symbol  Indices  Conditions 

material_holdup  \(M_{t,p,j}\)  t, p, j  has_holdup = True 
phase_fraction  \(\phi_{t,p}\)  t, p  has_holdup = True 
material_accumulation  \(\frac{\partial M_{t,p,j}}{\partial t}\)  t, p, j  dynamic = True 
rate_reaction_generation  \(N_{kinetic,t,p,j}\)  t, p ,j  has_rate_reactions = True 
rate_reaction_extent  \(X_{kinetic,t,r}\)  t, r  has_rate_reactions = True 
equilibrium_reaction_generation  \(N_{equilibrium,t,p,j}\)  t, p ,j  has_equilibrium_reactions = True 
equilibrium_reaction_extent  \(X_{equilibrium,t,r}\)  t, r  has_equilibrium_reactions = True 
phase_equilibrium_generation  \(N_{pe,t,p,j}\)  t, p ,j  has_phase_equilibrium = True 
mass_transfer_term  \(N_{transfer,t,p,j}\)  t, p ,j  has_mass_transfer = True 
Constraints
material_balances(t, p, j):
The \(N_{custom, t, p, j}\) term allows the user to provide custom terms (variables or expressions) in both mass and molar basis which will be added into the material balances, which will be converted as necessary to the same basis as the material balance (by multiplying or dividing by the component molecular weight). The basis of the material balance is determined by the physical property package, and if undefined (or not mass or mole basis), an Exception will be returned.
If has_holdup is True, material_holdup_calculation(t, p, j):
where \(\rho_{t, p ,j}\) is the density of component \(j\) in phase \(p\) at time \(t\)
If dynamic is True:
Numerical discretization of the derivative terms, \(\frac{\partial M_{t,p,j}}{\partial t}\), will be performed by Pyomo.DAE.
If has_rate_reactions is True, rate_reaction_stoichiometry_constraint(t, p, j):
where \(\alpha_{r, p. j}\) is the stoichiometric coefficient of component \(j\) in phase \(p\) for reaction \(r\) (as defined in the PhysicalParameterBlock).
If has_equilibrium_reactions argument is True, equilibrium_reaction_stoichiometry_constraint(t, p, j):
where \(\alpha_{r, p. j}\) is the stoichiometric coefficient of component \(j\) in phase \(p\) for reaction \(r\) (as defined in the PhysicalParameterBlock).
Material balances are written for each component across all phases (e.g. one balance for both liquid water and steam). Most terms in the balance equations are still indexed by both phase and component however. Physical property packages may include information to indicate that certain species do not appear in all phases, and material balances will not be written in these cases (if has_holdup is True holdup terms will still appear for these species, however these will be set to 0).
Variables
Variable Name  Symbol  Indices  Conditions 

material_holdup  \(M_{t,p,j}\)  t, p, j  has_holdup = True 
phase_fraction  \(\phi_{t,p}\)  t, p  has_holdup = True 
material_accumulation  \(\frac{\partial M_{t,p,j}}{\partial t}\)  t, p, j  dynamic = True 
rate_reaction_generation  \(N_{kinetic,t,p,j}\)  t, p ,j  has_rate_reactions = True 
rate_reaction_extent  \(X_{kinetic,t,r}\)  t, r  has_rate_reactions = True 
equilibrium_reaction_generation  \(N_{equilibrium,t,p,j}\)  t, p ,j  has_equilibrium_reactions = True 
equilibrium_reaction_extent  \(X_{equilibrium,t,r}\)  t, r  has_equilibrium_reactions = True 
mass_transfer_term  \(N_{transfer,t,p,j}\)  t, p ,j  has_mass_transfer = True 
Constraints
material_balances(t, j):
The \(N_{custom, t, j}\) term allows the user to provide custom terms (variables or expressions) in both mass and molar basis which will be added into the material balances, which will be converted as necessary to the same basis as the material balance (by multiplying or dividing by the component molecular weight). The basis of the material balance is determined by the physical property package, and if undefined (or not mass or mole basis), an Exception will be returned.
If has_holdup is True, material_holdup_calculation(t, p, j):
where \(\rho_{t, p ,j}\) is the density of component \(j\) in phase \(p\) at time \(t\)
If dynamic is True:
Numerical discretization of the derivative terms, \(\frac{\partial M_{t,p,j}}{\partial t}\), will be performed by Pyomo.DAE.
If has_rate_reactions is True,, rate_reaction_stoichiometry_constraint(t, p, j):
where \(\alpha_{r, p. j}\) is the stoichiometric coefficient of component \(j\) in phase \(p\) for reaction \(r\) (as defined in the PhysicalParameterBlock).
If has_equilibrium_reactions argument is True, equilibrium_reaction_stoichiometry_constraint(t, p, j):
where \(\alpha_{r, p. j}\) is the stoichiometric coefficient of component \(j\) in phase \(p\) for reaction \(r\) (as defined in the PhysicalParameterBlock).
Material balances are written for each element in the mixture.
Variables
Variable Name  Symbol  Indices  Conditions 

element_holdup  \(M_{t,e}\)  t, e  has_holdup = True 
phase_fraction  \(\phi_{t,p}\)  t, p  has_holdup = True 
element_accumulation  \(\frac{\partial M_{t,e}}{\partial t}\)  t, e  dynamic = True 
elemental_mass_transfer_term  \(N_{transfer,t,e}\)  t, e  has_mass_transfer = True 
Expressions
elemental_flow_in(t, p, e):
elemental_flow_out(t, p, e):
where \(n_{j, e}\) is the number of moles of element \(e\) in component \(j\).
Constraints
element_balances(t, e):
The \(N_{custom, t, e}\) term allows the user to provide custom terms (variables or expressions) which will be added into the material balances.
If has_holdup is True, elemental_holdup_calculation(t, e):
where \(\rho_{t, p ,j}\) is the density of component \(j\) in phase \(p\) at time \(t\)
If dynamic is True:
Numerical discretization of the derivative terms, \(\frac{\partial M_{t,e}}{\partial t}\), will be performed by Pyomo.DAE.
A single enthalpy balance is written for the entire mixture.
Variables
Variable Name  Symbol  Indices  Conditions 

enthalpy_holdup  \(E_{t,p}\)  t, p  has_holdup = True 
phase_fraction  \(\phi_{t,p}\)  t, p  has_holdup = True 
enthalpy_accumulation  \(\frac{\partial E_{t,p}}{\partial t}\)  t, p  dynamic = True 
heat  \(Q_{t}\)  t  has_heat_transfer = True 
work  \(W_{t}\)  t  has_work_transfer = True 
Expressions
heat_of_reaction(t):
where \(Q_{rxn, t}\) is the total enthalpy released by both kinetic and equilibrium reactions, and \(\Delta H_{rxn, r}\) is the specific heat of reaction for reaction \(r\).
Parameters
Parameter Name  Symbol  Default Value 

scaling_factor_energy  \(s_{energy}\)  1E6 
Constraints
enthalpy_balance(t):
The \(E_{custom, t}\) term allows the user to provide custom terms which will be added into the energy balance.
If has_holdup is True, enthalpy_holdup_calculation(t, p):
where \(h_{t, p}\) is the enthalpy density (specific enthalpy) of phase \(p\) at time \(t\)
If dynamic is True:
Numerical discretization of the derivative terms, \(\frac{\partial E_{t,p}}{\partial t}\), will be performed by Pyomo.DAE.
A single pressure balance is written for the entire mixture.
Variables
Variable Name  Symbol  Indices  Conditions 

deltaP  \(\Delta P_{t}\)  t  has_pressure_change = True 
Parameters
Parameter Name  Symbol  Default Value 

scaling_factor_pressure  \(s_{pressure}\)  1E4 
Constraints
pressure_balance(t):
The \(\Delta P_{custom, t}\) term allows the user to provide custom terms which will be added into the pressure balance.
1D Control Volume ClassÂ¶
The ControlVolume1DBlock block is used for systems with one spatial dimension where material flows parallel to the spatial domain. Examples of these types of unit operations include plug flow reactors and pipes. ControlVolume1DBlock blocks are discretized along the length domain and contain one StateBlock and one ReactionBlock (if applicable) at each point in the domain (including the inlet and outlet).

class
idaes.core.control_volume1d.
ControlVolume1DBlock
(*args, **kwargs)Â¶ ControlVolume1DBlock is a specialized Pyomo block for IDAES control volume blocks discretized in one spatial direction, and contains instances of ControlVolume1DBlockData.
ControlVolume1DBlock should be used for any control volume with a defined volume and distinct inlets and outlets where there is a single spatial domain parallel to the material flow direction. This encompases unit operations such as plug flow reactors and pipes.
Parameters:  rule (function) â€“ A rule function or None. Default rule calls build().
 concrete (bool) â€“ If True, make this a toplevel model. Default  False.
 ctype (str) â€“ Pyomo ctype of the block. Default  â€śBlockâ€ť
 default (dict) â€“
Default ProcessBlockData config
 Keys
 dynamic
 Indicates whether this model will be dynamic, default  useDefault. Valid values: { useDefault  get flag from parent, True  set as a dynamic model, False  set as a steadystate model}
 has_holdup
 Indicates whether holdup terms should be constructed or not. Must be True if dynamic = True, default  False. Valid values: { True  construct holdup terms, False  do not construct holdup terms}
 property_package
 Property parameter object used to define property calculations, default  useDefault. Valid values: { useDefault  use default package from parent model or flowsheet, PropertyParameterObject  a PropertyParameterBlock object.}
 property_package_args
 A ConfigBlock with arguments to be passed to a property block(s) and used when constructing these, default  None. Valid values: { see property package for documentation.}
 reaction_package
 Reaction parameter object used to define reaction calculations, default  None. Valid values: { None  no reaction package, ReactionParameterBlock  a ReactionParameterBlock object.}
 reaction_package_args
 A ConfigBlock with arguments to be passed to a reaction block(s) and used when constructing these, default  None. Valid values: { see reaction package for documentation.}
 auto_construct
 If set to True, this argument will trigger the auto_construct method which will attempt to construct a set of material, energy and momentum balance equations based on the parent unitâ€™s config block. The parent unit must have a config block which derives from CONFIG_Base, default  False. Valid values: { True  use automatic construction, False  do not use automatic construciton.}
 area_definition
 Argument defining whether area variable should be spatially variant or not. default  DistributedVars.uniform. Valid values: { DistributedVars.uniform  area does not vary across spatial domian, DistributedVars.variant  area can vary over the domain and is indexed by time and space.}
 transformation_method
 Method to use to transform domain. Must be a method recognised by the Pyomo TransformationFactory.
 transformation_scheme
 Scheme to use when transformating domain. See Pyomo documentation for supported schemes.
 finite_elements
 Number of finite elements to use in transformation (equivalent to Pyomo nfe argument).
 collocation_points
 Number of collocation points to use (equivalent to Pyomo ncp argument).
 initialize (dict) â€“ ProcessBlockData config for individual elements. Keys are BlockData indexes and values are dictionaries described under the â€śdefaultâ€ť argument above.
 idx_map (function) â€“ Function to take the index of a BlockData element and return the index in the initialize dict from which to read arguments. This can be provided to overide the default behavior of matching the BlockData index exactly to the index in initialize.
Returns: (ControlVolume1DBlock) New instance

class
idaes.core.control_volume1d.
ControlVolume1DBlockData
(component)[source]Â¶ 1Dimensional ControlVolume Class
This class forms the core of all 1D IDAES models. It provides methods to build property and reaction blocks, and add mass, energy and momentum balances. The form of the terms used in these constraints is specified in the chosen property package.

add_geometry
(length_domain=None, length_domain_set=[0.0, 1.0], flow_direction=<FlowDirection.forward: 1>)[source]Â¶ Method to create spatial domain and volume Var in ControlVolume.
Parameters:   (length_domain_set) â€“ domain for the ControlVolume. If not provided, a new ContinuousSet will be created (default=None). ContinuousSet should be normalized to run between 0 and 1.
  â€“ a new ContinuousSet if length_domain is not provided (default = [0.0, 1.0]).
  argument indicating direction of material flow (flow_direction) â€“
 relative to length domain. Valid values:
 FlowDirection.forward (default), flow goes from 0 to 1.
 FlowDirection.backward, flow goes from 1 to 0
Returns: None

add_phase_component_balances
(has_rate_reactions=False, has_equilibrium_reactions=False, has_phase_equilibrium=False, has_mass_transfer=False, custom_molar_term=None, custom_mass_term=None)[source]Â¶ This method constructs a set of 1D material balances indexed by time, length, phase and component.
Parameters:  has_rate_reactions â€“ whether default generation terms for rate reactions should be included in material balances
 has_equilibrium_reactions â€“ whether generation terms should for chemical equilibrium reactions should be included in material balances
 has_phase_equilibrium â€“ whether generation terms should for phase equilibrium behaviour should be included in material balances
 has_mass_transfer â€“ whether generic mass transfer terms should be included in material balances
 custom_molar_term â€“ a Pyomo Expression representing custom terms to be included in material balances on a molar basis. Expression must be indexed by time, length domain, phase list and component list
 custom_mass_term â€“ a Pyomo Expression representing custom terms to be included in material balances on a mass basis. Expression must be indexed by time, length domain, phase list and component list
Returns: Constraint object representing material balances

add_phase_energy_balances
(*args, **kwargs)[source]Â¶ Method for adding energy balances (including kinetic energy) indexed by phase to the control volume.
See specific control volume documentation for details.

add_phase_enthalpy_balances
(*args, **kwargs)[source]Â¶ Method for adding enthalpy balances indexed by phase to the control volume.
See specific control volume documentation for details.

add_phase_momentum_balances
(*args, **kwargs)[source]Â¶ Method for adding momentum balances indexed by phase to the control volume.
See specific control volume documentation for details.

add_phase_pressure_balances
(*args, **kwargs)[source]Â¶ Method for adding pressure balances indexed by phase to the control volume.
See specific control volume documentation for details.

add_reaction_blocks
(has_equilibrium=None)[source]Â¶ This method constructs the reaction block for the control volume.
Parameters:  has_equilibrium â€“ indicates whether equilibrium calculations will be required in reaction block
 package_arguments â€“ dictlike object of arguments to be passed to reaction block as construction arguments
Returns: None

add_state_blocks
(information_flow=<FlowDirection.forward: 1>, has_phase_equilibrium=None)[source]Â¶ This method constructs the state blocks for the control volume.
Parameters:  information_flow â€“ a FlowDirection Enum indicating whether information flows from inlettooutlet or outlettoinlet
 has_phase_equilibrium â€“ indicates whether equilibrium calculations will be required in state blocks
 package_arguments â€“ dictlike object of arguments to be passed to state blocks as construction arguments
Returns: None

add_total_component_balances
(has_rate_reactions=False, has_equilibrium_reactions=False, has_phase_equilibrium=False, has_mass_transfer=False, custom_molar_term=None, custom_mass_term=None)[source]Â¶ This method constructs a set of 1D material balances indexed by time length and component.
Parameters:  has_rate_reactions â€“ whether default generation terms for rate reactions should be included in material balances
 has_equilibrium_reactions â€“ whether generation terms should for chemical equilibrium reactions should be included in material balances
 has_phase_equilibrium â€“ whether generation terms should for phase equilibrium behaviour should be included in material balances
 has_mass_transfer â€“ whether generic mass transfer terms should be included in material balances
 custom_molar_term â€“ a Pyomo Expression representing custom terms to be included in material balances on a molar basis. Expression must be indexed by time, length domain and component list
 custom_mass_term â€“ a Pyomo Expression representing custom terms to be included in material balances on a mass basis. Expression must be indexed by time, length domain and component list
Returns: Constraint object representing material balances

add_total_element_balances
(has_rate_reactions=False, has_equilibrium_reactions=False, has_phase_equilibrium=False, has_mass_transfer=False, custom_elemental_term=None)[source]Â¶ This method constructs a set of 1D element balances indexed by time and length.
Parameters:   whether default generation terms for rate (has_rate_reactions) â€“ reactions should be included in material balances
  whether generation terms should for (has_equilibrium_reactions) â€“ chemical equilibrium reactions should be included in material balances
  whether generation terms should for phase (has_phase_equilibrium) â€“ equilibrium behaviour should be included in material balances
  whether generic mass transfer terms should be (has_mass_transfer) â€“ included in material balances
  a Pyomo Expression representing custom (custom_elemental_term) â€“ terms to be included in material balances on a molar elemental basis. Expression must be indexed by time, length and element list
Returns: Constraint object representing material balances

add_total_energy_balances
(*args, **kwargs)[source]Â¶ Method for adding a total energy balance (including kinetic energy) to the control volume.
See specific control volume documentation for details.

add_total_enthalpy_balances
(has_heat_of_reaction=False, has_heat_transfer=False, has_work_transfer=False, custom_term=None)[source]Â¶ This method constructs a set of 1D enthalpy balances indexed by time and phase.
Parameters:   whether terms for heat of reaction should (has_heat_of_reaction) â€“ be included in enthalpy balance
  whether terms for heat transfer should be (has_heat_transfer) â€“ included in enthalpy balances
  whether terms for work transfer should be (has_work_transfer) â€“ included in enthalpy balances
  a Pyomo Expression representing custom terms to (custom_term) â€“ be included in enthalpy balances. Expression must be indexed by time, length and phase list
Returns: Constraint object representing enthalpy balances

add_total_material_balances
(*args, **kwargs)[source]Â¶ Method for adding a total material balance to the control volume.
See specific control volume documentation for details.

add_total_momentum_balances
(*args, **kwargs)[source]Â¶ Method for adding a total momentum balance to the control volume.
See specific control volume documentation for details.

add_total_pressure_balances
(has_pressure_change=False, custom_term=None)[source]Â¶ This method constructs a set of 1D pressure balances indexed by time.
Parameters:   whether terms for pressure change should be (has_pressure_change) â€“ included in enthalpy balances
  a Pyomo Expression representing custom terms to (custom_term) â€“ be included in pressure balances. Expression must be indexed by time and length domain
Returns: Constraint object representing pressure balances

apply_transformation
()[source]Â¶ Method to apply DAE transformation to the Control Volume length domain. Transformation applied will be based on the Control Volume configuration arguments.

initialize
(state_args=None, outlvl=0, optarg=None, solver='ipopt', hold_state=True)[source]Â¶ Initialisation routine for 1D control volume (default solver ipopt)
Keyword Arguments:  state_args â€“ a dict of arguments to be passed to the property package(s) to provide an initial state for initialization (see documentation of the specific property package) (default = {}).
 outlvl â€“ sets output level of initialisation routine. Valid values: 0  no output (default), 1  return solver state for each step in routine, 2  include solver output infomation (tee=True)
 optarg â€“ solver options dictionary object (default=None)
 solver â€“ str indicating whcih solver to use during initialization (default = â€ipoptâ€™)
 hold_state â€“ flag indicating whether the initialization routine should unfix any state variables fixed during initialization, default  True. Valid values: True  states variables are not unfixed, and a dict of returned containing flags for which states were fixed during initialization, False  state variables are unfixed after initialization by calling the release_state method.
Returns: If hold_states is True, returns a dict containing flags for which states were fixed during initialization else the release state is triggered.

model_check
()[source]Â¶ This method executes the model_check methods on the associated state blocks (if they exist). This method is generally called by a unit model as part of the unitâ€™s model_check method.
Parameters: None â€“ Returns: None

release_state
(flags, outlvl=0)[source]Â¶ Method to release state variables fixed during initialisation.
Keyword Arguments:  flags â€“ dict containing information of which state variables were fixed during initialization, and should now be unfixed. This dict is returned by initialize if hold_state = True.
 outlvl â€“ sets output level of logging
Returns: None

This section documents the variables and constraints created by each of the methods provided by the ControlVolume0DBlock class.
 \(t\) indicates time index
 \(x\) indicates spatial (length) index
 \(p\) indicates phase index
 \(j\) indicates component index
 \(e\) indicates element index
 \(r\) indicates reaction name index
Most terms within the balance equations written by ControlVolume1DBlock are on a basis of per unit length (e.g. \(mol/m \cdot s\)).
The add_geometry method creates the normalized length domain for the control volume (or a reference to an external domain). All constraints in ControlVolume1DBlock assume a normalized length domain, with values between 0 and 1.
This method also adds variables and constraints to describe the geometry of the control volume. ControlVolume1DBlock does not support varying dimensions of the control volume with time at this stage.
Variables
Variable Name  Symbol  Indices  Conditions 

length_domain  \(x\)  None  None 
volume  \(V\)  None  None 
area  \(A\)  None  None 
length  \(L\)  None  None 
Constraints
geometry_constraint:
Material balances are written for each component in each phase (e.g. separate balances for liquid water and steam). Physical property packages may include information to indicate that certain species do not appear in all phases, and material balances will not be written in these cases (if has_holdup is True holdup terms will still appear for these species, however these will be set to 0).
Variables
Variable Name  Symbol  Indices  Conditions 

material_holdup  \(M_{t,x,p,j}\)  t, x, p, j  has_holdup = True 
phase_fraction  \(\phi_{t,x,p}\)  t, x, p  has_holdup = True 
material_accumulation  \(\frac{\partial M_{t,x,p,j}}{\partial t}\)  t, x, p, j  dynamic = True 
_flow_terms  \(F_{t, x, p, j}\)  t, x, p, j  None 
material_flow_dx  \(\frac{\partial F_{t,x,p,j}}{\partial x}\)  t, x, p, j  None 
rate_reaction_generation  \(N_{kinetic,t,x,p,j}\)  t, x, p ,j  has_rate_reactions = True 
rate_reaction_extent  \(X_{kinetic,t,x,r}\)  t, x, r  has_rate_reactions = True 
equilibrium_reaction_generation  \(N_{equilibrium,t,x,p,j}\)  t, x, p ,j  has_equilibrium_reactions = True 
equilibrium_reaction_extent  \(X_{equilibrium,t,x,r}\)  t, x, r  has_equilibrium_reactions = True 
phase_equilibrium_generation  \(N_{pe,t,x,p,j}\)  t, x, p ,j  has_phase_equilibrium = True 
mass_transfer_term  \(N_{transfer,t,x,p,j}\)  t, x, p ,j  has_mass_transfer = True 
Constraints
material_balances(t, x, p, j):
\(fd\) is a flow direction term, which allows for material flow to be defined in either direction. If material flow is defined as forward, \(fd = 1\), otherwise \(fd = 1\).
The \(N_{custom, t, x, p, j}\) term allows the user to provide custom terms (variables or expressions) in both mass and molar basis which will be added into the material balances, which will be converted as necessary to the same basis as the material balance (by multiplying or dividing by the component molecular weight). The basis of the material balance is determined by the physical property package, and if undefined (or not mass or mole basis), an Exception will be returned.
material_flow_linking_constraints(t, x, p, j):
This constraint is an internal constraint used to link the extensive material flow terms in the StateBlocks into a single indexed variable. This is required as Pyomo.DAE requires a single indexed variable to create the associated DerivativeVars and their numerical expansions.
If has_holdup is True, material_holdup_calculation(t, x, p, j):
where \(\rho_{t, x, p ,j}\) is the density of component \(j\) in phase \(p\) at time \(t\) and location \(x\).
If dynamic is True:
Numerical discretization of the derivative terms, \(\frac{\partial M_{t,x,p,j}}{\partial t}\), will be performed by Pyomo.DAE.
If has_rate_reactions is True, rate_reaction_stoichiometry_constraint(t, x, p, j):
where \(\alpha_{r, p. j}\) is the stoichiometric coefficient of component \(j\) in phase \(p\) for reaction \(r\) (as defined in the PhysicalParameterBlock).
If has_equilibrium_reactions argument is True, equilibrium_reaction_stoichiometry_constraint(t, x, p, j):
where \(\alpha_{r, p. j}\) is the stoichiometric coefficient of component \(j\) in phase \(p\) for reaction \(r\) (as defined in the PhysicalParameterBlock).
Material balances are written for each component across all phases (e.g. one balance for both liquid water and steam). Physical property packages may include information to indicate that certain species do not appear in all phases, and material balances will not be written in these cases (if has_holdup is True holdup terms will still appear for these species, however these will be set to 0).
Variables
Variable Name  Symbol  Indices  Conditions 

material_holdup  \(M_{t,x,p,j}\)  t, x, p, j  has_holdup = True 
phase_fraction  \(\phi_{t,x,p}\)  t, x, p  has_holdup = True 
material_accumulation  \(\frac{\partial M_{t,x,p,j}}{\partial t}\)  t, x, p, j  dynamic = True 
_flow_terms  \(F_{t, x, p, j}\)  t, x, p, j  None 
material_flow_dx  \(\frac{\partial F_{t,x,p,j}}{\partial x}\)  t, x, p, j  None 
rate_reaction_generation  \(N_{kinetic,t,x,p,j}\)  t, x, p ,j  has_rate_reactions = True 
rate_reaction_extent  \(X_{kinetic,t,x,r}\)  t, x, r  has_rate_reactions = True 
equilibrium_reaction_generation  \(N_{equilibrium,t,x,p,j}\)  t, x, p ,j  has_equilibrium_reactions = True 
equilibrium_reaction_extent  \(X_{equilibrium,t,x,r}\)  t, x, r  has_equilibrium_reactions = True 
mass_transfer_term  \(N_{transfer,t,x,p,j}\)  t, x, p ,j  has_mass_transfer = True 
Constraints
material_balances(t, x, p, j):
\(fd\) is a flow direction term, which allows for material flow to be defined in either direction. If material flow is defined as forward, \(fd = 1\), otherwise \(fd = 1\).
The \(N_{custom, t, x, j}\) term allows the user to provide custom terms (variables or expressions) in both mass and molar basis which will be added into the material balances, which will be converted as necessary to the same basis as the material balance (by multiplying or dividing by the component molecular weight). The basis of the material balance is determined by the physical property package, and if undefined (or not mass or mole basis), an Exception will be returned.
material_flow_linking_constraints(t, x, p, j):
This constraint is an internal constraint used to link the extensive material flow terms in the StateBlocks into a single indexed variable. This is required as Pyomo.DAE requires a single indexed variable to create the associated DerivativeVars and their numerical expansions.
If has_holdup is True, material_holdup_calculation(t, x, p, j):
where \(\rho_{t, x, p ,j}\) is the density of component \(j\) in phase \(p\) at time \(t\) and location \(x\).
If dynamic is True:
Numerical discretization of the derivative terms, \(\frac{\partial M_{t,x,p,j}}{\partial t}\), will be performed by Pyomo.DAE.
If has_rate_reactions is True, rate_reaction_stoichiometry_constraint(t, x, p, j):
where \(\alpha_{r, p. j}\) is the stoichiometric coefficient of component \(j\) in phase \(p\) for reaction \(r\) (as defined in the PhysicalParameterBlock).
If has_equilibrium_reactions argument is True, equilibrium_reaction_stoichiometry_constraint(t, x, p, j):
where \(\alpha_{r, p. j}\) is the stoichiometric coefficient of component \(j\) in phase \(p\) for reaction \(r\) (as defined in the PhysicalParameterBlock).
Material balances are written for each element in the mixture.
Variables
Variable Name  Symbol  Indices  Conditions 

element_holdup  \(M_{t,x,e}\)  t, x, e  has_holdup = True 
phase_fraction  \(\phi_{t,x,p}\)  t, x, p  has_holdup = True 
element_accumulation  \(\frac{\partial M_{t,x,e}}{\partial t}\)  t, x, e  dynamic = True 
elemental_mass_transfer_term  \(N_{transfer,t,x,e}\)  t, x, e  has_mass_transfer = True 
elemental_flow_term  \(F_{t,x,e}\)  t, x, e  None 
Constraints
elemental_flow_constraint(t, x, e):
where \(n_{j, e}\) is the number of moles of element \(e\) in component \(j\).
element_balances(t, x, e):
\(fd\) is a flow direction term, which allows for material flow to be defined in either direction. If material flow is defined as forward, \(fd = 1\), otherwise \(fd = 1\).
The \(N_{custom, t, x, e}\) term allows the user to provide custom terms (variables or expressions) which will be added into the material balances.
If has_holdup is True, elemental_holdup_calculation(t, x, e):
where \(\rho_{t, x, p ,j}\) is the density of component \(j\) in phase \(p\) at time \(t\) and location \(x\).
If dynamic is True:
Numerical discretization of the derivative terms, \(\frac{\partial M_{t,x,p,j}}{\partial t}\), will be performed by Pyomo.DAE.
A single enthalpy balance is written for the entire mixture at each point in the spatial domain.
Variables
Variable Name  Symbol  Indices  Conditions 

enthalpy_holdup  \(E_{t,x,p}\)  t, x, p  has_holdup = True 
phase_fraction  \(\phi_{t,x,p}\)  t, x, p  has_holdup = True 
enthalpy_accumulation  \(\frac{\partial E_{t,x,p}}{\partial t}\)  t, x, p  dynamic = True 
_enthalpy_flow  \(H_{t,x,p}\)  t, x, p  None 
enthalpy_flow_dx  \(\frac{\partial H_{t,x,p}}{\partial x}\)  t, x, p  None 
heat  \(Q_{t,x}\)  t, x  has_heat_transfer = True 
work  \(W_{t,x}\)  t, x  has_work_transfer = True 
Expressions
heat_of_reaction(t, x):
where \(Q_{rxn, t, x}\) is the total enthalpy released by both kinetic and equilibrium reactions, and \(\Delta H_{rxn, r}\) is the specific heat of reaction for reaction \(r\).
Parameters
Parameter Name  Symbol  Default Value 

scaling_factor_energy  \(s_{energy}\)  1E6 
Constraints
enthalpy_balance(t):
\(fd\) is a flow direction term, which allows for material flow to be defined in either direction. If material flow is defined as forward, \(fd = 1\), otherwise \(fd = 1\).
The \(E_{custom, t, x}\) term allows the user to provide custom terms which will be added into the energy balance.
enthalpy_flow_linking_constraints(t, x, p):
This constraint is an internal constraint used to link the extensive enthalpy flow terms in the StateBlocks into a single indexed variable. This is required as Pyomo.DAE requires a single indexed variable to create the associated DerivativeVars and their numerical expansions.
If has_holdup is True, enthalpy_holdup_calculation(t, x, p):
where \(h_{t, x, p}\) is the enthalpy density (specific enthalpy) of phase \(p\) at time \(t\) and location \(x\).
If dynamic is True:
Numerical discretization of the derivative terms, \(\frac{\partial E_{t,x,p}}{\partial t}\), will be performed by Pyomo.DAE.
A single pressure balance is written for the entire mixture at all points in the spatial domain.
Variables
Variable Name  Symbol  Indices  Conditions 

pressure  \(P_{t,x}\)  t, x  None 
pressure_dx  \(\frac{\partial P_{t,x}}{\partial x}\)  t, x  None 
deltaP  \(\Delta P_{t,x}\)  t, x  has_pressure_change = True 
Parameters
Parameter Name  Symbol  Default Value 

scaling_factor_pressure  \(s_{pressure}\)  1E4 
Constraints
pressure_balance(t, x):
\(fd\) is a flow direction term, which allows for material flow to be defined in either direction. If material flow is defined as forward, \(fd = 1\), otherwise \(fd = 1\).
The \(\Delta P_{custom, t, x}\) term allows the user to provide custom terms which will be added into the pressure balance.
pressure_linking_constraint(t, x):
This constraint is an internal constraint used to link the pressure terms in the StateBlocks into a single indexed variable. This is required as Pyomo.DAE requires a single indexed variable to create the associated DerivativeVars and their numerical expansions.
Control Volumes are the center of the IDAES process modeling framework, and serve as the fundamental building block of all unit operations. Control Volumes represent a single, welldefined volume of material over which material, energy and/or momentum balances will be performed.
The IDAES Control Volume classes are designed to facilitate the construction of these balance equations by providing the model developer with a set of prebuilt methods to perform the most common tasks in developing models of unit operations. The Control Volume classes contain methods for creating and linking the necessary property calculations and writing common forms of the balance equations so that the model developer can focus their time on the aspects that make each unit model unique.
The IDAES process modeling framework currently supports two types of Control Volume:
ControlVolume0DBlock
represents a single wellmixed volume of material with a single inlet and a single outlet. This type of control volume is sufficient to model most inletoutlet type unit operations which do not require spatial discretization.ControlVolume1DBlock
represents a volume with spatial variation in one dimension parallel to the material flow. This type of control volume is useful for representing flow in pipes and simple 1D flow reactors.
Common Control Volume TasksÂ¶
All of the IDAES Control Volume classes are built on a common core (ControlVolumeBlockData
) which defines a set of common tasks required for all Control Volumes. The more specific Control Volume classes then build upon these common tasks to provide tools appropriate for their specific application.
All Control Volume classes begin with the following tasks:
 Determine if the
ControlVolume
should be steadystate or dynamic.  Get the time domain.
 Determine whether material and energy holdups should be calculated.
 Collect information necessary for creating
StateBlocks
andReactionBlocks
.  Create references to
phase_list
andcomponent_list
Sets in thePhysicalParameterBlock
.
More details on these steps is provided later.
Setting up the time domainÂ¶
The first common task the Control Volume block performs is to determine if it should be dynamic or steadystate and to collect the time domain from the UnitModel. Control Volume blocks have an argument dynamic
which can be provided during construction which specifies if the Control Volume should be dynamic (dynamic=True
) or steadystate (dynamic=False
). If the argument is not provided, the Control Volume block will inherit this argument from its parent UnitModel
.
Finally, the Control Volume checks that the has_holdup
argument is consistent with the dynamic
argument, and raises a ConfigurationError
if it is not.
Getting Property Package InformationÂ¶
If a reference to a property package was not provided by the UnitModel
as an argument, the Control Volume first checks to see if the UnitModel
has a property_package
argument set, and uses this if present. Otherwise, the Control Volume block begins searching up the model tree looking for an argument named default_property_package
and uses the first of these that it finds. If no default_property_package
is found, a ConfigurationError
is returned.
Collecting Indexing Sets for Property PackageÂ¶
The final common step for all Control Volumes is to collect any required indexing sets from the physical property package (for example component and phase lists). These are used by the Control Volume for determining what balance equations need to be written, and what terms to create.
The indexing sets the Control Volume looks for are:
component_list
 used to determine what components are present, and thus what material balances are requiredphase_list
 used to determine what phases are present, and thus what balance equations are required
ControlVolume and ControlVolumeBlockData ClassesÂ¶
A key purpose of Control Volumes is to automate as much of the task of writing a unit model as possible. For this purpose, Control Volumes support a number of methods for common tasks model developers may want to perform. The specifics of these methods will be different between different types of Control Volumes, and certain methods may not be applicable to some types of Control Volumes (in which case a NotImplementedError
will be returned). A full list of potential methods is provided here, however users should check the documentation for the specific Control Volume they are using for more details on what methods are supported in that specific Control Volume.

class
idaes.core.control_volume_base.
ControlVolume
(*args, **kwargs)Â¶ This class is not usually used directly. Use ControlVolume0DBlock or ControlVolume1DBlock instead.
Parameters:  rule (function) â€“ A rule function or None. Default rule calls build().
 concrete (bool) â€“ If True, make this a toplevel model. Default  False.
 ctype (str) â€“ Pyomo ctype of the block. Default  â€śBlockâ€ť
 default (dict) â€“
Default ProcessBlockData config
 Keys
 dynamic
 Indicates whether this model will be dynamic, default  useDefault. Valid values: { useDefault  get flag from parent, True  set as a dynamic model, False  set as a steadystate model}
 has_holdup
 Indicates whether holdup terms should be constructed or not. Must be True if dynamic = True, default  False. Valid values: { True  construct holdup terms, False  do not construct holdup terms}
 property_package
 Property parameter object used to define property calculations, default  useDefault. Valid values: { useDefault  use default package from parent model or flowsheet, PropertyParameterObject  a PropertyParameterBlock object.}
 property_package_args
 A ConfigBlock with arguments to be passed to a property block(s) and used when constructing these, default  None. Valid values: { see property package for documentation.}
 reaction_package
 Reaction parameter object used to define reaction calculations, default  None. Valid values: { None  no reaction package, ReactionParameterBlock  a ReactionParameterBlock object.}
 reaction_package_args
 A ConfigBlock with arguments to be passed to a reaction block(s) and used when constructing these, default  None. Valid values: { see reaction package for documentation.}
 auto_construct
 If set to True, this argument will trigger the auto_construct method which will attempt to construct a set of material, energy and momentum balance equations based on the parent unitâ€™s config block. The parent unit must have a config block which derives from CONFIG_Base, default  False. Valid values: { True  use automatic construction, False  do not use automatic construciton.}
 initialize (dict) â€“ ProcessBlockData config for individual elements. Keys are BlockData indexes and values are dictionaries described under the â€śdefaultâ€ť argument above.
 idx_map (function) â€“ Function to take the index of a BlockData element and return the index in the initialize dict from which to read arguments. This can be provided to overide the default behavior of matching the BlockData index exactly to the index in initialize.
Returns: (ControlVolume) New instance

class
idaes.core.control_volume_base.
ControlVolumeBlockData
(component)[source]Â¶ The ControlVolumeBlockData Class forms the base class for all IDAES ControlVolume models. The purpose of this class is to automate the tasks common to all control volume blockss and ensure that the necessary attributes of a control volume block are present.
The most signfiicant role of the ControlVolumeBlockData class is to set up the construction arguments for the control volume block, automatically link to the time domain of the parent block, and to get the information about the property and reaction packages.

add_energy_balances
(balance_type=<EnergyBalanceType.useDefault: 1>, **kwargs)[source]Â¶ General method for adding energy balances to a control volume. This method makes calls to specialised submethods for each type of energy balance.
Parameters:  balance_type (EnergyBalanceType) â€“ Enum indicating which type of energy balance should be constructed.
 has_heat_of_reaction (bool) â€“ whether terms for heat of reaction should be included in energy balance
 has_heat_transfer (bool) â€“ whether generic heat transfer terms should be included in energy balances
 has_work_transfer (bool) â€“ whether generic mass transfer terms should be included in energy balances
 custom_term (Expression) â€“ a Pyomo Expression representing custom terms to be included in energy balances
Returns: Constraint objects constructed by submethod

add_geometry
(*args, **kwargs)[source]Â¶ Method for defining the geometry of the control volume.
See specific control volume documentation for details.

add_material_balances
(balance_type=<MaterialBalanceType.useDefault: 1>, **kwargs)[source]Â¶ General method for adding material balances to a control volume. This method makes calls to specialised submethods for each type of material balance.
Parameters:   MaterialBalanceType Enum indicating which type of (balance_type) â€“ material balance should be constructed.
  whether default generation terms for rate (has_rate_reactions) â€“ reactions should be included in material balances
  whether generation terms should for (has_equilibrium_reactions) â€“ chemical equilibrium reactions should be included in material balances
  whether generation terms should for phase (has_phase_equilibrium) â€“ equilibrium behaviour should be included in material balances
  whether generic mass transfer terms should be (has_mass_transfer) â€“ included in material balances
  a Pyomo Expression representing custom terms to (custom_mass_term) â€“ be included in material balances on a molar basis.
  a Pyomo Expression representing custom terms to â€“ be included in material balances on a mass basis.
Returns: Constraint objects constructed by submethod

add_momentum_balances
(balance_type=<MomentumBalanceType.pressureTotal: 1>, **kwargs)[source]Â¶ General method for adding momentum balances to a control volume. This method makes calls to specialised submethods for each type of momentum balance.
Parameters:  balance_type (MomentumBalanceType) â€“ Enum indicating which type of momentum balance should be constructed. Default = MomentumBalanceType.pressureTotal.
 has_pressure_change (bool) â€“ whether default generation terms for pressure change should be included in momentum balances
 custom_term (Expression) â€“ a Pyomo Expression representing custom terms to be included in momentum balances
Returns: Constraint objects constructed by submethod

add_phase_component_balances
(*args, **kwargs)[source]Â¶ Method for adding material balances indexed by phase and component to the control volume.
See specific control volume documentation for details.

add_phase_energy_balances
(*args, **kwargs)[source]Â¶ Method for adding energy balances (including kinetic energy) indexed by phase to the control volume.
See specific control volume documentation for details.

add_phase_enthalpy_balances
(*args, **kwargs)[source]Â¶ Method for adding enthalpy balances indexed by phase to the control volume.
See specific control volume documentation for details.

add_phase_momentum_balances
(*args, **kwargs)[source]Â¶ Method for adding momentum balances indexed by phase to the control volume.
See specific control volume documentation for details.

add_phase_pressure_balances
(*args, **kwargs)[source]Â¶ Method for adding pressure balances indexed by phase to the control volume.
See specific control volume documentation for details.

add_reaction_blocks
(*args, **kwargs)[source]Â¶ Method for adding ReactionBlocks to the control volume.
See specific control volume documentation for details.

add_state_blocks
(*args, **kwargs)[source]Â¶ Method for adding StateBlocks to the control volume.
See specific control volume documentation for details.

add_total_component_balances
(*args, **kwargs)[source]Â¶ Method for adding material balances indexed by component to the control volume.
See specific control volume documentation for details.

add_total_element_balances
(*args, **kwargs)[source]Â¶ Method for adding total elemental material balances indexed to the control volume.
See specific control volume documentation for details.

add_total_energy_balances
(*args, **kwargs)[source]Â¶ Method for adding a total energy balance (including kinetic energy) to the control volume.
See specific control volume documentation for details.

add_total_enthalpy_balances
(*args, **kwargs)[source]Â¶ Method for adding a total enthalpy balance to the control volume.
See specific control volume documentation for details.

add_total_material_balances
(*args, **kwargs)[source]Â¶ Method for adding a total material balance to the control volume.
See specific control volume documentation for details.

add_total_momentum_balances
(*args, **kwargs)[source]Â¶ Method for adding a total momentum balance to the control volume.
See specific control volume documentation for details.

AutoConstruct MethodÂ¶
To reduce the demands on unit model developers even further, Control Volumes have an optional autoconstruct feature that will attempt to populate the Control Volume based on a set of instructions provided at the Unit Model level. If the auto_construct
configuration argument is set to True, the following methods are called automatically in the following order when instantiating the Control Volume.
add_geometry
add_state_blocks
add_reaction_blocks
add_material_balances
add_energy_balances
add_momentum_balances
apply_transformation
To determine what terms are required for the balance equations, the Control Volume expects the Unit Model to have the following configuration arguments, which are used as arguments to the methods above.
dynamic
has_holdup
material_balance_type
energy_balance_type
momentum_balance_type
has_rate_reactions
has_equilibrium_reactions
has_phase_equilibrium
has_mass_transfer
has_heat_of_reaction
has_heat_transfer
has_work_transfer
has_pressure_change
property_package
property_package_args
reaction_package
reaction_package_args
For convenience, a template ConfigBlock
(named CONFIG_Template) is available in the control_volume_base.py
module which contains all the necessary arguments which can be inherited by unit models wishing to use the autoconstruct feature.
Utility MethodsÂ¶
Homotopy MetaSolverÂ¶
The IDAES homotopy metasolver is useful for cases where a user has a feasible solution to a welldefined (i.e. square) problem at one set of conditions (i.e. value of fixed variables), and wishes to find a feasible solution to the same problem at a different set of conditions. In many situations this can be achieved by directly changing the values of the fixed variables to their new values and solving the problem, but cases exist where this is challenging. Homotopy solvers try to find a feasible path to the new solution by taking smaller steps in the value of the fixed variables to progressively find a solution at the new point.
Note
A homotopy solver should not be considered a fix to a poorly posed or illconditioned problem, and users should first consider whether their problem can be reformulated for better performance.
The IDAES homotopy routine starts from a feasible solution to the problem at the initial values for the fixed variables (\(v_0\)) and a set of target values for these (\(t\)). The routine then calculates a set of new values for the fixed variables during the first homotopy evaluation based on an initial step size \(s_0\) such that:
The problem is then passed to Ipopt to try to find a solution at the current values for the fixed variables. Based on the success or failure of the solver step, the following occurs:
 If the solver returns an optimal solution, the step is accepted and the solution to the current state of the model is saved (to provide a feasible point to revert to in case a future step fails). If the current metasolver progress is 1 (i.e. it has converged to the target values), the metasolver terminates otherwise the metasolver progress (\(p_i\)) is then updated, \(p_i = p_{i1} + s_i\), and the size of the next homotopy step is then calculated based on an adaptive step size method such that:
where \(I_a\) is the number of solver iterations required in the current homotopy step, \(I_t\) is the desired number of solver iterations per homotopy step (an input parameter to the homotopy routine) and \(a\) is a step size acceleration factor (another input parameter). As such, the size of the homotopy step is adjusted to try to achieve a desired number of solver iterations per step as a proxy for difficulty in solving each step. If new step would overshoot the target values, then the step size is cut back to match the target values. The user can also specify a maximum and/or minimum size for the homotopy which can be used to limit the homotopy step.
A new set of values for the fixed variables is calculated using \(v_{i+1} = t \times (p_i+s_{i+1}) + v_0 \times (1(p_i+s_{i+1}))\) and the process repeated.
 If the solver fails to find an optimal solution (for any reason), the current step is rejected and solution to the previous successful step is reloaded. If the last homotopy step was equal to the minimum homotopy step size, the metasolver terminates, otherwise, a reduced homotopy step is calculated using:
where \(c\) is a step cut factor (an input parameter between 0.1 and 0.9). If the new step homotopy step is less than the minimum homotopy step size, the minimum step is used instead.
A new set of fixed variable values are then calculated and another attempt to solve the problem is made.
The homotopy metasolver has the following possible termination conditions (using the Pyomo TerminationCondition Enum):
 TerminationCondition.optimal  metasolver successfully converged at the target values for the fixed variables.
 TerminationCondition.other  the metasolver successfully converged at the target values for the fixed variables, but with regularization of during final step. Users are recommended to discard this solution.
 TerminationCondition.minStepLength  the metasolver was unable to find a feasible path to the target values, as the solver failed to find a solution using the minimum homotopy step size.
 TerminationCondition.maxEvaluations  the metasolver terminated due to reaching the maximum allowed number of attempted homotopy steps
 TerminationCondition.infeasible  could not find feasible solution to the problem at the initial values for the fixed variables.
IDAES Homotopy metasolver routine.

idaes.core.util.homotopy.
homotopy
(model, variables, targets, max_solver_iterations=50, max_solver_time=10, step_init=0.1, step_cut=0.5, iter_target=4, step_accel=0.5, max_step=1, min_step=0.05, max_eval=200)[source]Â¶ Homotopy metasolver routine using Ipopt as the nonlinear solver. This routine takes a model along with a list of fixed variables in that model and a list of target values for those variables. The routine then tries to iteratively move the values of the fixed variables to their target values using an adaptive step size.
Parameters:  model â€“ model to be solved
 variables â€“ list of Pyomo Var objects to be varied using homotopy. Variables must be fixed.
 targets â€“ list of target values for each variable
 max_solver_iterations â€“ maximum number of solver iterations per homotopy step (default=50)
 max_solver_time â€“ maximum cpu time for the solver per homotopy step (default=10)
 step_init â€“ initial homotopy step size (default=0.1)
 step_cut â€“ factor by which to reduce step size on failed step (default=0.5)
 step_accel â€“ acceleration factor for adjusting step size on successful step (default=0.5)
 iter_target â€“ target number of solver iterations per homotopy step (default=4)
 max_step â€“ maximum homotopy step size (default=1)
 min_step â€“ minimum homotopy step size (default=0.05)
 max_eval â€“ maximum number of homotopy evaluations (both successful and unsuccessful) (default=200)
Returns:  A Pyomo TerminationCondition Enum indicating
how the metasolver terminated (see documentation)
 Solver Progress : a fraction indication how far the solver progressed
from the initial values to the target values
 Number of Iterations : number of homotopy evaluations before solver
terminated
Return type: Termination Condition
Initialization MethodsÂ¶
The IDAES toolset contains a number of utility functions to assist users with initializing models.
This module contains utility functions for initialization of IDAES models.

idaes.core.util.initialization.
fix_state_vars
(blk, state_args={})[source]Â¶ Method for fixing state variables within StateBlocks. Method takes an optional argument of values to use when fixing variables.
Parameters:  blk â€“ An IDAES StateBlock object in which to fix the state variables
 state_args â€“ a dict containing values to use when fixing state variables. Keys must match with names used in the define_state_vars method, and indices of any variables must agree.
Returns: A dict keyed by block index, state variable name (as defined by define_state_variables) and variable index indicating the fixed status of each variable before the fix_state_vars method was applied.

idaes.core.util.initialization.
propagate_state
(stream, direction='forward')[source]Â¶ This method propagates values between Ports along Arcs. Values can be propagated in either direction using the direction argument.
Parameters:  stream â€“ Arc object along which to propagate values
 direction â€“ direction in which to propagate values. Default = â€forwardâ€™ Valid value: â€forwardâ€™, â€backwardâ€™.
Returns: None

idaes.core.util.initialization.
revert_state_vars
(blk, flags)[source]Â¶ Method to revert the fixed state of the state variables within an IDAES StateBlock based on a set of flags of the previous state.
Parameters:  blk â€“ an IDAES StateBlock
 flags â€“ a dict of bools indicating previous state with keys in the form (StateBlock index, state variable name (as defined by define_state_vars), var indices).
Returns: None

idaes.core.util.initialization.
solve_indexed_blocks
(solver, blocks, **kwds)[source]Â¶ This method allows for solving of Indexed Block components as if they were a single Block. A temporary Block object is created which is populated with the contents of the objects in the blocks argument and then solved.
Parameters:  solver â€“ a Pyomo solver object to use when solving the Indexed Block
 blocks â€“ an object which inherits from Block, or a list of Blocks
 kwds â€“ a dict of argumnets to be passed to the solver
Returns: A Pyomo solver results object
Model State SerializationÂ¶
The IDAES framework has some utility functions for serializing the state of a
Pyomo model. These functions can save and load attributes of Pyomo components,
but cannot reconstruct the Pyomo objects (it is not a replacement for pickle).
It does have some advantages over pickle though. Not all Pyomo models are
picklable. Serialization and deserialization of the model state to/from json is
more secure in that it only deals with data and not executable code. It should
be safe to use the from_json()
function with data from untrusted sources,
while, unpickling an object from an untrusted source is not secure. Storing a
model state using these functions is also probably more robust against Python
and Python package version changes, and possibly more suitable for longterm storage
of results.
Below are a few example use cases for this module.
 Some models are very complex and may take minutes to initialize. Once a model is initialized itâ€™s state can be saved. For future runs, the initialized state can be reloaded instead of rerunning the initialization procedure.
 Results can be stored for later evaluation without needing to rerun the model. These results can be archived in a data management system if needed later.
 These functions may be useful in writing initialization procedures. For example, a model may be constructed and ready to run but first it may need to be initialized. Which components are active and which variables are fixed can be stored. The initialization can change which variables are fixed and which components are active. The original state can be read back after initialization, but where only values of variables that were originally fixed are read back in. This is an easy way to ensure that whatever the initialization procedure may do, the result is exactly the same problem (with only better initial values for unfixed variables).
 These functions can be used to send and receive model data to/from JavaScript user interface components.
This section provides a few very simple examples of how to use these functions.
This section provides some boilerplate and functions to create a couple simple test models. The second model is a little more complicated and includes suffixes.
from pyomo.environ import *
from idaes.core.util import to_json, from_json, StoreSpec
def setup_model01():
model = ConcreteModel()
model.b = Block([1,2,3])
a = model.b[1].a = Var(bounds=(100, 100), initialize=2)
b = model.b[1].b = Var(bounds=(100, 100), initialize=20)
model.b[1].c = Constraint(expr=b==10*a)
a.fix(2)
return model
def setup_model02():
model = ConcreteModel()
a = model.a = Param(default=1, mutable=True)
b = model.b = Param(default=2, mutable=True)
c = model.c = Param(initialize=4)
x = model.x = Var([1,2], initialize={1:1.5, 2:2.5}, bounds=(10,10))
model.f = Objective(expr=(x[1]  a)**2 + (x[2]  b)**2)
model.g = Constraint(expr=x[1] + x[2]  c >= 0)
model.dual = Suffix(direction=Suffix.IMPORT)
model.ipopt_zL_out = Suffix(direction=Suffix.IMPORT)
model.ipopt_zU_out = Suffix(direction=Suffix.IMPORT)
return model
These examples can be appended to the boilerplate code above.
The first example creates a model, saves the state, changes a value, then reads back the initial state.
model = setup_model01()
to_json(model, fname="ex.json.gz", gz=True, human_read=True)
model.b[1].a = 3000.4
from_json(model, fname="ex.json.gz", gz=True)
print(value(model.b[1].a))
2
This next example show how to save only suffixes.
model = setup_model02()
# Suffixes here are read back from solver, so to have suffix data,
# need to solve first
solver = SolverFactory("ipopt")
solver.solve(model)
store_spec = StoreSpec.suffix()
to_json(model, fname="ex.json", wts=store_spec)
# Do something and now I want my suffixes back
from_json(model, fname="ex.json", wts=store_spec)
Despite the name of the to_json
function it is capable of creating Python
dictionaries, json files, gzipped json files, and json strings. The function
documentation is below. A StoreSpec
object provides the function with details on what to store and how to handle
special cases of Pyomo component attributes.

idaes.core.util.model_serializer.
to_json
(o, fname=None, human_read=False, wts=None, metadata={}, gz=False, return_dict=False, return_json_string=False)[source]Â¶ Save the state of a model to a Python dictionary, and optionally dump it to a json file. To load a model state, a model with the same structure must exist. The model itself cannot be recreated from this.
Parameters:  o â€“ The Pyomo component object to save. Usually a Pyomo model, but could also be a subcomponent of a model (usually a subblock).
 fname â€“ json file name to save model state, if None only create python dict
 gz â€“ If fname is given and gv is True gzip the json file. The default is False.
 human_read â€“ if True, add indents and spacing to make the json file more readable, if false cut out whitespace and make as compact as possilbe
 metadata â€“ A dictionary of addtional metadata to add.
 wts â€“ is What To Save, this is a StoreSpec object that specifies what object types and attributes to save. If None, the default is used which saves the state of the compelte model state.
 metadata â€“ addtional metadata to save beyond the standard format_version, date, and time.
 return_dict â€“ default is False if true returns a dictionary representation
 return_json_string â€“ default is False returns a json string
Returns: If return_dict is True returns a dictionary serialization of the Pyomo component. If return_dict is False and return_json_string is True returns a json string dump of the dict. If fname is given the dictionary is also written to a json file. If gz is True and fname is given, writes a gzipped json file.
The from_json
function puts data from Python dictionaries, json files,
gzipped json files, and json strings back into a Pyomo model. The function
documentation is below. A StoreSpec
object provides the function with details on what to read and how to handle
special cases of Pyomo component attributes.

idaes.core.util.model_serializer.
from_json
(o, sd=None, fname=None, s=None, wts=None, gz=False)[source]Â¶ Load the state of a Pyomo component state from a dictionary, json file, or json string. Must only specify one of sd, fname, or s as a nonNone value. This works by going through the model and loading the state of each subcompoent of o. If the saved state contains extra information, it is ignored. If the save state doesnâ€™t contain an enetry for a model component that is to be loaded an error will be raised, unless ignore_missing = True.
Parameters:  o â€“ Pyomo component to for which to load state
 sd â€“ State dictionary to load, if None, check fname and s
 fname â€“ JSON file to load, only used if sd is None
 s â€“ JSON string to load only used if both sd and fname are None
 wts â€“ StoreSpec object specifying what to load
 gz â€“ If True assume the file specified by fname is gzipped. The default is False.
Returns: Dictionary with some perfomance information. The keys are â€śetime_load_fileâ€ť, how long in seconds it took to load the json file â€śetime_read_dictâ€ť, how long in seconds it took to read models state â€śetime_read_suffixesâ€ť, how long in seconds it took to read suffixes
StoreSpec
is a class for objects that tell the to_json()
and from_json()
functions how to read and write Pyomo component attributes. The default
initialization provides an object that would load and save attributes usually
needed to save a model state. There are several other class methods that
provide canned objects for specific uses. Through initialization arguments, the
behavior is highly customizable. Attributes can be read or written using callback
functions to handle attributes that can not be directly read or written (e.g.
a variable lower bound is set by calling setlb()). See the class documentation below.

class
idaes.core.util.model_serializer.
StoreSpec
(classes=((<class 'pyomo.core.base.param.Param'>, ('_mutable', )), (<class 'pyomo.core.base.var.Var'>, ()), (<class 'pyomo.core.base.component.Component'>, ('active', ))), data_classes=((<class 'pyomo.core.base.var._VarData'>, ('fixed', 'stale', 'value', 'lb', 'ub')), (<class 'pyomo.core.base.param._ParamData'>, ('value', )), (<class 'int'>, ('value', )), (<class 'float'>, ('value', )), (<class 'pyomo.core.base.component.ComponentData'>, ('active', ))), skip_classes=(<class 'pyomo.core.base.external.ExternalFunction'>, <class 'pyomo.core.base.sets.Set'>, <class 'pyomo.network.port.Port'>, <class 'pyomo.core.base.expression.Expression'>, <class 'pyomo.core.base.rangeset.RangeSet'>), ignore_missing=True, suffix=True, suffix_filter=None)[source]Â¶ A StoreSpec object tells the serializer functions what to read or write. The default settings will produce a StoreSpec configured to load/save the typical attributes required to load/save a model state.
Parameters:  classes â€“ A list of classes to save. Each class is represented by a list (or tupple) containing the following elements: (1) class (compared using isinstance) (2) attribute list or None, an emptry list store the object, but none of its attributes, None will not store objects of this class type (3) optional load filter function. The load filter function returns a list of attributes to read based on the state of an object and its saved state. The allows, for example, loading values for unfixed variables, or only loading values whoes current value is less than one. The filter function only applies to load not save. Filter functions take two arguments (a) the object (current state) and (b) the dictionary containing the saved state of an object. More specific classes should come before more general classes. For example if an obejct is a HeatExchanger and a UnitModel, and HeatExchanger is listed first, it will follow the HeatExchanger settings. If UnitModel is listed first in the classes list, it will follow the UnitModel settings.
 data_classes â€“ This takes the same form as the classes argument. This is for component data classes.
 skip_classes â€“ This is a list of classes to skip. If a class appears in the skip list, but also appears in the classes argument, the classes argument will override skip_classes. The use for this is to specifically exclude certain classes that would get caught by more general classes (e.g. UnitModel is in the class list, but you want to exclude HeatExchanger which is derived from UnitModel).
 ignore_missing â€“ If True will ignore a component or attribute that exists in the model, but not in the stored state. If false an excpetion will be raised for things in the model that should be loaded but arenâ€™t in the stored state. Extra items in the stored state will not raise an exception regaurdless of this argument.
 suffix â€“ If True store suffixes and component ids. If false, donâ€™t store suffixes.
 suffix_filter â€“ None to store all siffixes if suffix=True, or a list of suffixes to store if suffix=True

get_class_attr_list
(o)[source]Â¶ Look up what attributes to save/load for an Component object. :param o: Object to look up attribute list for.
Returns: A list of attributes and a filter function for object type

get_data_class_attr_list
(o)[source]Â¶ Look up what attributes to save/load for an ComponentData object. :param o: Object to look up attribute list for.
Returns: A list of attributes and a filter function for object type

set_read_callback
(attr, cb=None)[source]Â¶ Set a callback to set an attribute, when reading from json or dict.

set_write_callback
(attr, cb=None)[source]Â¶ Set a callback to get an attribute, when writing to json or dict.
Python dictionaries, json strings, or json files are generated, in any case the structure of the data is the same. The current data structure version is 3.
The example json below shows the toplevel structure. The
"top_level_component"
would be the name of the Pyomo component that is being
serialized. The top level component is the only place were the component name does
not matter when reading the serialized data.
{
"__metadata__": {
"format_version": 3,
"date": "20181221",
"time": "11:34:39.714323",
"other": {
},
"__performance__": {
"n_components": 219,
"etime_make_dict": 0.003}
},
"top_level_component":{
"...": "..."
},
}
The data structure of a Pyomo component is shown below. Here "attribute_1"
and "attribute_2"
are just examples the actual attributes saved depend on
the â€śwtsâ€ť argument to to_json()
. Scalar and indexed components have the
same structure. Scalar components have one entry in "data"
with an index of
"None"
. Only components derived from Pyomoâ€™s _BlockData
have a "__pyomo_components__"
field, and components appearing there are keyed
by thier name. The data structure duplicates the hierarchical structure of the
Pyomo model.
Suffixes store extra attributes for Pyomo components that are not stored on the
components themselves. Suffixes are a Pyomo structure that comes from the AMPL
solver interface. If a component is a suffix, keys in the data section are the
serial integer component IDs generated by to_json()
, and the value is the
value of the suffix for the corresponding component.
{
"__type__": "<class 'some.class'>",
"__id__": 0,
"data":{
"index_1":{
"__type__":"<usually a component class but for params could be float, int, ...>",
"__id__": 1,
"__pyomo_components__":{
"child_component_1": {
"...": "..."
}
},
"attribute_1": "... could be any number of attributes like 'value': 1.0,",
"attribute_2": "..."
}
},
"attribute_1": "... could be any number of attributes like 'active': true,",
"attribute_2": "..."
}
As a more concrete example, here is the json generated for example model 2 in Examples. This code can be appended to the example boilerplate above. To generate the example json shown.
model = setup_model02()
solver = SolverFactory("ipopt")
solver.solve(model)
to_json(model, fname="ex.json")
The resulting json is shown below. The toplevel component
in this case is given as â€śunknown,â€ť because the model was not given a name. The
top level object name is not needed when reading back data, since the top level
object is specified in the call to from_json()
. Types are not used when
reading back data, they may have some future application, but at this point they
just provide a little extra information.
{
"__metadata__":{
"format_version":3,
"date":"20190102",
"time":"10:22:25.833501",
"other":{
},
"__performance__":{
"n_components":18,
"etime_make_dict":0.0009555816650390625
}
},
"unknown":{
"__type__":"<class 'pyomo.core.base.PyomoModel.ConcreteModel'>",
"__id__":0,
"active":true,
"data":{
"None":{
"__type__":"<class 'pyomo.core.base.PyomoModel.ConcreteModel'>",
"__id__":1,
"active":true,
"__pyomo_components__":{
"a":{
"__type__":"<class 'pyomo.core.base.param.SimpleParam'>",
"__id__":2,
"_mutable":true,
"data":{
"None":{
"__type__":"<class 'pyomo.core.base.param.SimpleParam'>",
"__id__":3,
"value":1
}
}
},
"b":{
"__type__":"<class 'pyomo.core.base.param.SimpleParam'>",
"__id__":4,
"_mutable":true,
"data":{
"None":{
"__type__":"<class 'pyomo.core.base.param.SimpleParam'>",
"__id__":5,
"value":2
}
}
},
"c":{
"__type__":"<class 'pyomo.core.base.param.SimpleParam'>",
"__id__":6,
"_mutable":false,
"data":{
"None":{
"__type__":"<class 'pyomo.core.base.param.SimpleParam'>",
"__id__":7,
"value":4
}
}
},
"x":{
"__type__":"<class 'pyomo.core.base.var.IndexedVar'>",
"__id__":8,
"data":{
"1":{
"__type__":"<class 'pyomo.core.base.var._GeneralVarData'>",
"__id__":9,
"fixed":false,
"stale":false,
"value":1.5,
"lb":10,
"ub":10
},
"2":{
"__type__":"<class 'pyomo.core.base.var._GeneralVarData'>",
"__id__":10,
"fixed":false,
"stale":false,
"value":2.5,
"lb":10,
"ub":10
}
}
},
"f":{
"__type__":"<class 'pyomo.core.base.objective.SimpleObjective'>",
"__id__":11,
"active":true,
"data":{
"None":{"__type__":"<class 'pyomo.core.base.objective.SimpleObjective'>",
"__id__":12,
"active":true
}
}
},
"g":{
"__type__":"<class 'pyomo.core.base.constraint.SimpleConstraint'>",
"__id__":13,
"active":true,
"data":{
"None":{
"__type__":"<class 'pyomo.core.base.constraint.SimpleConstraint'>",
"__id__":14,
"active":true
}
}
},
"dual":{
"__type__":"<class 'pyomo.core.base.suffix.Suffix'>",
"__id__":15,
"active":true,
"data":{
"14":0.9999999626149493
}
},
"ipopt_zL_out":{
"__type__":"<class 'pyomo.core.base.suffix.Suffix'>",
"__id__":16,
"active":true,
"data":{
"9":2.1791814146763388e10,
"10":2.004834508495852e10
}
},
"ipopt_zU_out":{
"__type__":"<class 'pyomo.core.base.suffix.Suffix'>",
"__id__":17,
"active":true,
"data":{
"9":2.947875485096964e10,
"10":3.3408951850535573e10
}
}
}
}
}
}
}
Model Statistics MethodsÂ¶
The IDAES toolset contains a number of utility functions which are useful for quantifying model statistics such as the number of variable and constraints, and calculating the available degrees of freedom in a model. These methods can be found in idaes.core.util.model_statistics
.
The most commonly used methods are degrees_of_freedom
and report_statistics
, which are described below.
The degrees_of_freedom
method calculates the number of degrees of freedom available in a given model. The calcuation is based on the number of unfixed variables which appear in active constraints, minus the number of active equality constraints in the model. Users should note that this method does not consider inequality or deactived constraints, or variables which do not appear in active equality constraints.
The report_statistics
method provides the user with a summary of the contents of their model, including the degrees of freedom and a break down of the different Variables
, Constraints
, Objectives
, Blocks
and Expressions
. This method also includes numbers of deactivated components for the user to use in debugging complex models.
Note
This method only considers Pyomo components in activated Blocks
. The number of deactivated Blocks
is reported, but any components within these Blocks
are not included.
Example Output
Model Statistics
Degrees of Freedom: 0
Total No. Variables: 52
No. Fixed Variables: 12
No. Unused Variables: 0 (Fixed: 0)
No. Variables only in Inequalities: 0 (Fixed: 0)
Total No. Constraints: 40
No. Equality Constraints: 40 (Deactivated: 0)
No. Inequality Constraints: 0 (Deactivated: 0)
No. Objectives: 0 (Deactivated: 0)
No. Blocks: 14 (Deactivated: 0)
No. Expressions: 2

idaes.core.util.model_statistics.
report_statistics
(block, ostream=None)[source]Â¶ Method to print a report of the model statistics for a Pyomo Block
Parameters:  block â€“ the Block object to report statistics from
 ostream â€“ output stream for printing (defaults to sys.stdout)
Returns: Printed output of the model statistics
In addition to the methods discussed above, the model_statistics
module also contains a number of methods for quantifying model statistics which may be of use to the user in debugging models. These methods come in three types:
 Number methods (start with
number_
) return the number of components which meet a given criteria, and are useful for quickly quantifying differnt types of components within a model for determining where problems may exist.  Set methods (end with
_set
) return a PyomoComponentSet
containing all components which meet a given criteria. These methods are useful for determining where a problem may exist, as theComponentSet
indicates which components may be causing a problem.  Generator methods (end with
_generator
) contain Pythongenerators
which return all components which meet a given criteria.
This module contains utility functions for reporting structural statistics of IDAES models.

idaes.core.util.model_statistics.
activated_block_component_generator
(block, ctype)[source]Â¶ Generator which returns all the components of a given ctype which exist in activated Blocks within a model.
Parameters:  block â€“ model to be studied
 ctype â€“ type of Pyomo component to be returned by generator.
Returns: A generator which returns all components of ctype which appear in activated Blocks in block

idaes.core.util.model_statistics.
activated_blocks_set
(block)[source]Â¶ Method to return a ComponentSet of all activated Block components in a model.
Parameters: block â€“ model to be studied Returns: A ComponentSet including all activated Block components in block (including block itself)

idaes.core.util.model_statistics.
activated_constraints_generator
(block)[source]Â¶ Generator which returns all activated Constraint components in a model.
Parameters: block â€“ model to be studied Returns: A generator which returns all activated Constraint components block

idaes.core.util.model_statistics.
activated_constraints_set
(block)[source]Â¶ Method to return a ComponentSet of all activated Constraint components in a model.
Parameters: block â€“ model to be studied Returns: A ComponentSet including all activated Constraint components in block

idaes.core.util.model_statistics.
activated_equalities_generator
(block)[source]Â¶ Generator which returns all activated equality Constraint components in a model.
Parameters: block â€“ model to be studied Returns: A generator which returns all activated equality Constraint components block

idaes.core.util.model_statistics.
activated_equalities_set
(block)[source]Â¶ Method to return a ComponentSet of all activated equality Constraint components in a model.
Parameters: block â€“ model to be studied Returns: A ComponentSet including all activated equality Constraint components in block

idaes.core.util.model_statistics.
activated_inequalities_generator
(block)[source]Â¶ Generator which returns all activated inequality Constraint components in a model.
Parameters: block â€“ model to be studied Returns: A generator which returns all activated inequality Constraint components block

idaes.core.util.model_statistics.
activated_inequalities_set
(block)[source]Â¶ Method to return a ComponentSet of all activated inequality Constraint components in a model.
Parameters: block â€“ model to be studied Returns: A ComponentSet including all activated inequality Constraint components in block

idaes.core.util.model_statistics.
activated_objectives_generator
(block)[source]Â¶ Generator which returns all activated Objective components in a model.
Parameters: block â€“ model to be studied Returns: A generator which returns all activated Objective components block

idaes.core.util.model_statistics.
activated_objectives_set
(block)[source]Â¶ Method to return a ComponentSet of all activated Objective components which appear in a model.
Parameters: block â€“ model to be studied Returns: A ComponentSet including all activated Objective components which appear in block

idaes.core.util.model_statistics.
active_variables_in_deactivated_blocks_set
(block)[source]Â¶ Method to return a ComponentSet of any Var components which appear within an active Constraint but belong to a deacitvated Block in a model.
Parameters: block â€“ model to be studied Returns: A ComponentSet including any Var components which belong to a deacitvated Block but appear in an activate Constraint in block

idaes.core.util.model_statistics.
deactivated_blocks_set
(block)[source]Â¶ Method to return a ComponentSet of all deactivated Block components in a model.
Parameters: block â€“ model to be studied Returns: A ComponentSet including all deactivated Block components in block (including block itself)

idaes.core.util.model_statistics.
deactivated_constraints_generator
(block)[source]Â¶ Generator which returns all deactivated Constraint components in a model.
Parameters: block â€“ model to be studied Returns: A generator which returns all deactivated Constraint components block

idaes.core.util.model_statistics.
deactivated_constraints_set
(block)[source]Â¶ Method to return a ComponentSet of all deactivated Constraint components in a model.
Parameters: block â€“ model to be studied Returns: A ComponentSet including all deactivated Constraint components in block

idaes.core.util.model_statistics.
deactivated_equalities_generator
(block)[source]Â¶ Generator which returns all deactivated equality Constraint components in a model.
Parameters: block â€“ model to be studied Returns: A generator which returns all deactivated equality Constraint components block

idaes.core.util.model_statistics.
deactivated_equalities_set
(block)[source]Â¶ Method to return a ComponentSet of all deactivated equality Constraint components in a model.
Parameters: block â€“ model to be studied Returns: A ComponentSet including all deactivated equality Constraint components in block

idaes.core.util.model_statistics.
deactivated_inequalities_generator
(block)[source]Â¶ Generator which returns all deactivated inequality Constraint components in a model.
Parameters: block â€“ model to be studied Returns: A generator which returns all indeactivated equality Constraint components block

idaes.core.util.model_statistics.
deactivated_inequalities_set
(block)[source]Â¶ Method to return a ComponentSet of all deactivated inequality Constraint components in a model.
Parameters: block â€“ model to be studied Returns: A ComponentSet including all deactivated inequality Constraint components in block

idaes.core.util.model_statistics.
deactivated_objectives_generator
(block)[source]Â¶ Generator which returns all deactivated Objective components in a model.
Parameters: block â€“ model to be studied Returns: A generator which returns all deactivated Objective components block

idaes.core.util.model_statistics.
deactivated_objectives_set
(block)[source]Â¶ Method to return a ComponentSet of all deactivated Objective components which appear in a model.
Parameters: block â€“ model to be studied Returns: A ComponentSet including all deactivated Objective components which appear in block

idaes.core.util.model_statistics.
derivative_variables_set
(block)[source]Â¶ Method to return a ComponentSet of all DerivativeVar components which appear in a model. Users should note that DerivativeVars are converted to ordinary Vars when a DAE transformation is applied. Thus, this method is useful for detecting any DerivativeVars which were do transformed.
Parameters: block â€“ model to be studied Returns: A ComponentSet including all DerivativeVar components which appear in block

idaes.core.util.model_statistics.
expressions_set
(block)[source]Â¶ Method to return a ComponentSet of all Expression components which appear in a model.
Parameters: block â€“ model to be studied Returns: A ComponentSet including all Expression components which appear in block

idaes.core.util.model_statistics.
fixed_unused_variables_set
(block)[source]Â¶ Method to return a ComponentSet of all fixed Var components which do not appear within any activated Constraint in a model.
Parameters: block â€“ model to be studied Returns: A ComponentSet including all fixed Var components which do not appear within any Constraints in block

idaes.core.util.model_statistics.
fixed_variables_generator
(block)[source]Â¶ Generator which returns all fixed Var components in a model.
Parameters: block â€“ model to be studied Returns: A generator which returns all fixed Var components block

idaes.core.util.model_statistics.
fixed_variables_in_activated_equalities_set
(block)[source]Â¶ Method to return a ComponentSet of all fixed Var components which appear within an equality Constraint in a model.
Parameters: block â€“ model to be studied Returns: A ComponentSet including all fixed Var components which appear within activated equality Constraints in block

idaes.core.util.model_statistics.
fixed_variables_only_in_inequalities
(block)[source]Â¶ Method to return a ComponentSet of all fixed Var components which appear only within activated inequality Constraints in a model.
Parameters: block â€“ model to be studied Returns: A ComponentSet including all fixed Var components which appear only within activated inequality Constraints in block

idaes.core.util.model_statistics.
fixed_variables_set
(block)[source]Â¶ Method to return a ComponentSet of all fixed Var components in a model.
Parameters: block â€“ model to be studied Returns: A ComponentSet including all fixed Var components in block

idaes.core.util.model_statistics.
large_residuals_set
(block, tol=1e05)[source]Â¶ Method to return a ComponentSet of all Constraint components with a residual greater than a given threshold which appear in a model.
Parameters:  block â€“ model to be studied
 tol â€“ residual threshold for inclusion in ComponentSet
Returns: A ComponentSet including all Constraint components with a residual greater than tol which appear in block

idaes.core.util.model_statistics.
number_activated_blocks
(block)[source]Â¶ Method to return the number of activated Block components in a model.
Parameters: block â€“ model to be studied Returns: Number of activated Block components in block (including block itself)

idaes.core.util.model_statistics.
number_activated_constraints
(block)[source]Â¶ Method to return the number of activated Constraint components in a model.
Parameters: block â€“ model to be studied Returns: Number of activated Constraint components in block

idaes.core.util.model_statistics.
number_activated_equalities
(block)[source]Â¶ Method to return the number of activated equality Constraint components in a model.
Parameters: block â€“ model to be studied Returns: Number of activated equality Constraint components in block

idaes.core.util.model_statistics.
number_activated_inequalities
(block)[source]Â¶ Method to return the number of activated inequality Constraint components in a model.
Parameters: block â€“ model to be studied Returns: Number of activated inequality Constraint components in block

idaes.core.util.model_statistics.
number_activated_objectives
(block)[source]Â¶ Method to return the number of activated Objective components which appear in a model.
Parameters: block â€“ model to be studied Returns: Number of activated Objective components which appear in block

idaes.core.util.model_statistics.
number_active_variables_in_deactivated_blocks
(block)[source]Â¶ Method to return the number of Var components which appear within an active Constraint but belong to a deacitvated Block in a model.
Parameters: block â€“ model to be studied Returns: Number of Var components which belong to a deacitvated Block but appear in an activate Constraint in block

idaes.core.util.model_statistics.
number_deactivated_blocks
(block)[source]Â¶ Method to return the number of deactivated Block components in a model.
Parameters: block â€“ model to be studied Returns: Number of deactivated Block components in block (including block itself)

idaes.core.util.model_statistics.
number_deactivated_constraints
(block)[source]Â¶ Method to return the number of deactivated Constraint components in a model.
Parameters: block â€“ model to be studied Returns: Number of deactivated Constraint components in block

idaes.core.util.model_statistics.
number_deactivated_equalities
(block)[source]Â¶ Method to return the number of deactivated equality Constraint components in a model.
Parameters: block â€“ model to be studied Returns: Number of deactivated equality Constraint components in block

idaes.core.util.model_statistics.
number_deactivated_inequalities
(block)[source]Â¶ Method to return the number of deactivated inequality Constraint components in a model.
Parameters: block â€“ model to be studied Returns: Number of deactivated inequality Constraint components in block

idaes.core.util.model_statistics.
number_deactivated_objectives
(block)[source]Â¶ Method to return the number of deactivated Objective components which appear in a model.
Parameters: block â€“ model to be studied Returns: Number of deactivated Objective components which appear in block

idaes.core.util.model_statistics.
number_derivative_variables
(block)[source]Â¶ Method to return the number of DerivativeVar components which appear in a model. Users should note that DerivativeVars are converted to ordinary Vars when a DAE transformation is applied. Thus, this method is useful for detecting any DerivativeVars which were do transformed.
Parameters: block â€“ model to be studied Returns: Number of DerivativeVar components which appear in block

idaes.core.util.model_statistics.
number_expressions
(block)[source]Â¶ Method to return the number of Expression components which appear in a model.
Parameters: block â€“ model to be studied Returns: Number of Expression components which appear in block

idaes.core.util.model_statistics.
number_fixed_unused_variables
(block)[source]Â¶ Method to return the number of fixed Var components which do not appear within any activated Constraint in a model.
Parameters: block â€“ model to be studied Returns: Number of fixed Var components which do not appear within any activated Constraints in block

idaes.core.util.model_statistics.
number_fixed_variables
(block)[source]Â¶ Method to return the number of fixed Var components in a model.
Parameters: block â€“ model to be studied Returns: Number of fixed Var components in block

idaes.core.util.model_statistics.
number_fixed_variables_in_activated_equalities
(block)[source]Â¶ Method to return the number of fixed Var components which appear within activated equality Constraints in a model.
Parameters: block â€“ model to be studied Returns: Number of fixed Var components which appear within activated equality Constraints in block

idaes.core.util.model_statistics.
number_fixed_variables_only_in_inequalities
(block)[source]Â¶ Method to return the number of fixed Var components which only appear within activated inequality Constraints in a model.
Parameters: block â€“ model to be studied Returns: Number of fixed Var components which only appear within activated inequality Constraints in block

idaes.core.util.model_statistics.
number_large_residuals
(block, tol=1e05)[source]Â¶ Method to return the number Constraint components with a residual greater than a given threshold which appear in a model.
Parameters:  block â€“ model to be studied
 tol â€“ residual threshold for inclusion in ComponentSet
Returns: Number of Constraint components with a residual greater than tol which appear in block

idaes.core.util.model_statistics.
number_total_blocks
(block)[source]Â¶ Method to return the number of Block components in a model.
Parameters: block â€“ model to be studied Returns: Number of Block components in block (including block itself)

idaes.core.util.model_statistics.
number_total_constraints
(block)[source]Â¶ Method to return the total number of Constraint components in a model.
Parameters: block â€“ model to be studied Returns: Number of Constraint components in block

idaes.core.util.model_statistics.
number_total_equalities
(block)[source]Â¶ Method to return the total number of equality Constraint components in a model.
Parameters: block â€“ model to be studied Returns: Number of equality Constraint components in block

idaes.core.util.model_statistics.
number_total_inequalities
(block)[source]Â¶ Method to return the total number of inequality Constraint components in a model.
Parameters: block â€“ model to be studied Returns: Number of inequality Constraint components in block

idaes.core.util.model_statistics.
number_total_objectives
(block)[source]Â¶ Method to return the number of Objective components which appear in a model
Parameters: block â€“ model to be studied Returns: Number of Objective components which appear in block

idaes.core.util.model_statistics.
number_unfixed_variables
(block)[source]Â¶ Method to return the number of unfixed Var components in a model.
Parameters: block â€“ model to be studied Returns: Number of unfixed Var components in block

idaes.core.util.model_statistics.
number_unfixed_variables_in_activated_equalities
(block)[source]Â¶ Method to return the number of unfixed Var components which appear within activated equality Constraints in a model.
Parameters: block â€“ model to be studied Returns: Number of unfixed Var components which appear within activated equality Constraints in block

idaes.core.util.model_statistics.
number_unused_variables
(block)[source]Â¶ Method to return the number of Var components which do not appear within any activated Constraint in a model.
Parameters: block â€“ model to be studied Returns: Number of Var components which do not appear within any activagted Constraints in block

idaes.core.util.model_statistics.
number_variables
(block)[source]Â¶ Method to return the number of Var components in a model.
Parameters: block â€“ model to be studied Returns: Number of Var components in block

idaes.core.util.model_statistics.
number_variables_in_activated_constraints
(block)[source]Â¶ Method to return the number of Var components that appear within active Constraints in a model.
Parameters: block â€“ model to be studied Returns: Number of Var components which appear within active Constraints in block

idaes.core.util.model_statistics.
number_variables_in_activated_equalities
(block)[source]Â¶ Method to return the number of Var components which appear within activated equality Constraints in a model.
Parameters: block â€“ model to be studied Returns: Number of Var components which appear within activated equality Constraints in block

idaes.core.util.model_statistics.
number_variables_in_activated_inequalities
(block)[source]Â¶ Method to return the number of Var components which appear within activated inequality Constraints in a model.
Parameters: block â€“ model to be studied Returns: Number of Var components which appear within activated inequality Constraints in block

idaes.core.util.model_statistics.
number_variables_near_bounds
(block, tol=0.0001)[source]Â¶ Method to return the number of all Var components in a model which have a value within tol (relative) of a bound.
Parameters:  block â€“ model to be studied
 tol â€“ relative tolerance for inclusion in generator (default = 1e4)
Returns: Number of components block that are close to a bound

idaes.core.util.model_statistics.
number_variables_only_in_inequalities
(block)[source]Â¶ Method to return the number of Var components which appear only within activated inequality Constraints in a model.
Parameters: block â€“ model to be studied Returns: Number of Var components which appear only within activated inequality Constraints in block

idaes.core.util.model_statistics.
total_blocks_set
(block)[source]Â¶ Method to return a ComponentSet of all Block components in a model.
Parameters: block â€“ model to be studied Returns: A ComponentSet including all Block components in block (including block itself)

idaes.core.util.model_statistics.
total_constraints_set
(block)[source]Â¶ Method to return a ComponentSet of all Constraint components in a model.
Parameters: block â€“ model to be studied Returns: A ComponentSet including all Constraint components in block

idaes.core.util.model_statistics.
total_equalities_generator
(block)[source]Â¶ Generator which returns all equality Constraint components in a model.
Parameters: block â€“ model to be studied Returns: A generator which returns all equality Constraint components block

idaes.core.util.model_statistics.
total_equalities_set
(block)[source]Â¶ Method to return a ComponentSet of all equality Constraint components in a model.
Parameters: block â€“ model to be studied Returns: A ComponentSet including all equality Constraint components in block

idaes.core.util.model_statistics.
total_inequalities_generator
(block)[source]Â¶ Generator which returns all inequality Constraint components in a model.
Parameters: block â€“ model to be studied Returns: A generator which returns all inequality Constraint components block

idaes.core.util.model_statistics.
total_inequalities_set
(block)[source]Â¶ Method to return a ComponentSet of all inequality Constraint components in a model.
Parameters: block â€“ model to be studied Returns: A ComponentSet including all inequality Constraint components in block

idaes.core.util.model_statistics.
total_objectives_generator
(block)[source]Â¶ Generator which returns all Objective components in a model.
Parameters: block â€“ model to be studied Returns: A generator which returns all Objective components block

idaes.core.util.model_statistics.
total_objectives_set
(block)[source]Â¶ Method to return a ComponentSet of all Objective components which appear in a model.
Parameters: block â€“ model to be studied Returns: A ComponentSet including all Objective components which appear in block

idaes.core.util.model_statistics.
unfixed_variables_generator
(block)[source]Â¶ Generator which returns all unfixed Var components in a model.
Parameters: block â€“ model to be studied Returns: A generator which returns all unfixed Var components block

idaes.core.util.model_statistics.
unfixed_variables_in_activated_equalities_set
(block)[source]Â¶ Method to return a ComponentSet of all unfixed Var components which appear within an activated equality Constraint in a model.
Parameters: block â€“ model to be studied Returns: A ComponentSet including all unfixed Var components which appear within activated equality Constraints in block

idaes.core.util.model_statistics.
unfixed_variables_set
(block)[source]Â¶ Method to return a ComponentSet of all unfixed Var components in a model.
Parameters: block â€“ model to be studied Returns: A ComponentSet including all unfixed Var components in block

idaes.core.util.model_statistics.
unused_variables_set
(block)[source]Â¶ Method to return a ComponentSet of all Var components which do not appear within any activated Constraint in a model.
Parameters: block â€“ model to be studied Returns: A ComponentSet including all Var components which do not appear within any Constraints in block

idaes.core.util.model_statistics.
variables_in_activated_constraints_set
(block)[source]Â¶ Method to return a ComponentSet of all Var components which appear within a Constraint in a model.
Parameters: block â€“ model to be studied Returns: A ComponentSet including all Var components which appear within activated Constraints in block

idaes.core.util.model_statistics.
variables_in_activated_equalities_set
(block)[source]Â¶ Method to return a ComponentSet of all Var components which appear within an equality Constraint in a model.
Parameters: block â€“ model to be studied Returns: A ComponentSet including all Var components which appear within activated equality Constraints in block

idaes.core.util.model_statistics.
variables_in_activated_inequalities_set
(block)[source]Â¶ Method to return a ComponentSet of all Var components which appear within an inequality Constraint in a model.
Parameters: block â€“ model to be studied Returns: A ComponentSet including all Var components which appear within activated inequality Constraints in block

idaes.core.util.model_statistics.
variables_near_bounds_generator
(block, tol=0.0001)[source]Â¶ Generator which returns all Var components in a model which have a value within tol (relative) of a bound.
Parameters:  block â€“ model to be studied
 tol â€“ relative tolerance for inclusion in generator (default = 1e4)
Returns: A generator which returns all Var components block that are close to a bound

idaes.core.util.model_statistics.
variables_near_bounds_set
(block, tol=0.0001)[source]Â¶ Method to return a ComponentSet of all Var components in a model which have a value within tol (relative) of a bound.
Parameters:  block â€“ model to be studied
 tol â€“ relative tolerance for inclusion in generator (default = 1e4)
Returns: A ComponentSet including all Var components block that are close to a bound

idaes.core.util.model_statistics.
variables_only_in_inequalities
(block)[source]Â¶ Method to return a ComponentSet of all Var components which appear only within inequality Constraints in a model.
Parameters: block â€“ model to be studied Returns: A ComponentSet including all Var components which appear only within inequality Constraints in block
Table MethodsÂ¶
The IDAES toolset contians a number of methods for generating and dislpaying summary tables of data in the form of pandas DataFrames
.

idaes.core.util.tables.
create_stream_table_dataframe
(streams, true_state=False, time_point=0, orient='columns')[source]Â¶ Method to create a stream table in the form of a pandas dataframe. Method takes a dict with name keys and stream values. Use an OrderedDict to list the streams in a specific order, otherwise the dataframe can be sorted later.
Parameters:  streams â€“ dict with name keys and stream values. Names will be used as display names for stream table, and streams may be Arcs, Ports or StateBlocks.
 true_state â€“ indicated whether the stream table should contain the display variables define in the StateBlock (False, default) or the state variables (True).
 time_point â€“ point in the time domain at which to generate stream table (default = 0)
 orient â€“ orientation of stream table. Accepted values are â€columnsâ€™ (default) where streams are displayed as columns, or â€indexâ€™ where stream are displayed as rows.
Returns: A pandas DataFrame containing the stream table data.

idaes.core.util.tables.
generate_table
(blocks, attributes, heading=None)[source]Â¶ Create a Pandas DataFrame that contains a list of userdefined attributes from a set of Blocks.
Parameters:  blocks (dict) â€“ A dictionary with name keys and BlockData objects for values. Any name can be associated with a block. Use an OrderedDict to show the blocks in a specific order, otherwise the dataframe can be sorted later.
 attributes (list or tuple of strings) â€“ Attributes to report from a Block, can be a Var, Param, or Expression. If an attribute doesnâ€™t exist or doesnâ€™t have a valid value, it will be treated as missing data.
 heading (list or tuple of srings) â€“ A list of strings that will be used as column headings. If None the attribute names will be used.
Returns: A Pandas dataframe containing a data table
Return type: (DataFrame)
Core OverviewÂ¶
All components of the IDAES process modeling framework are built of Pyomo Block components (see Pyomo documentation).
The ProcessBlock class is the base class of IDAES models, and provides the common foundation for all other components.
FlowsheetModel objects represent the top level of the IDAES modeling hierarchy, and contain connected networks of unit models, or even contain other flowsheet models, which are connected by Pyomo Arcs.
Physical property packages supply information about a materialâ€™s state including physical properties and flow rates. Reaction property packages are used in systems where chemical reactions may take place, and supply information on reaction rates and stoichiometry, based on a materialâ€™s state.
Equipment models are derived from UnitModel. Unit models contain control volumes and have ports which can be used to connect material and energy flows between unit models. On top of the balance equations usually contained in control volumes unit models contain additional performance equations that may calculate things like heat and mass transfer or efficiency curves.
ControlVolumes are the basic building block used to construct unit models that contain material and energy holdup and flows in and out. These blocks contain energy, mass, and momentum balances, as well as state and reaction blocks associated with the material within the control volume.
More detail on the different types of modeling objects is available in the Modeling Concepts section.
Unit Model LibraryÂ¶
Continuous Stirred Tank ReactorÂ¶
The IDAES CSTR model represents a unit operation where a material stream undergoes some chemical reaction(s) in a wellmixed vessel.
Degrees of FreedomÂ¶
CSTRs generally have one degree of freedom. Typically, the fixed variable is reactor volume.
Model StructureÂ¶
The core CSTR unit model consists of a single ControlVolume0D
(named control_volume
) with one Inlet Port (named inlet
) and one Outlet Port (named outlet
).
Additional ConstraintsÂ¶
CSTR units write the following additional Constraints beyond those written by the ControlVolume Block.
where \(X_{t,r}\) is the extent of reaction of reaction \(r\) at time \(t\), \(V_t\) is the volume of the reacting material at time \(t\) (allows for varying reactor volume with time) and \(r_{t,r}\) is the volumetric rate of reaction of reaction \(r\) at time \(t\) (from the outlet property package).
VariablesÂ¶
CSTR units add the following additional Variables beyond those created by the ControlVolume Block.
Variable  Name  Notes 

\(V_t\)  volume  If has_holdup = True this is a reference to control_volume.volume , otherwise a Var attached to the Unit Model 
\(Q_t\)  heat  Only if has_heat_transfer = True , reference to control_volume.heat 
CSTR ClassÂ¶

class
idaes.unit_models.cstr.
CSTR
(*args, **kwargs)Â¶ Parameters:  rule (function) â€“ A rule function or None. Default rule calls build().
 concrete (bool) â€“ If True, make this a toplevel model. Default  False.
 ctype (str) â€“ Pyomo ctype of the block. Default  â€śBlockâ€ť
 default (dict) â€“
Default ProcessBlockData config
 Keys
 dynamic
 Indicates whether this model will be dynamic or not, default = useDefault. Valid values: { useDefault  get flag from parent (default = False), True  set as a dynamic model, False  set as a steadystate model.}
 has_holdup
 Indicates whether holdup terms should be constructed or not. Must be True if dynamic = True, default  False. Valid values: { True  construct holdup terms, False  do not construct holdup terms}
 material_balance_type
 Indicates what type of mass balance should be constructed, default  MaterialBalanceType.useDefault. Valid values: { MaterialBalanceType.useDefault  refer to property package for default balance type **MaterialBalanceType.none  exclude material balances, MaterialBalanceType.componentPhase  use phase component balances, MaterialBalanceType.componentTotal  use total component balances, MaterialBalanceType.elementTotal  use total element balances, MaterialBalanceType.total  use total material balance.}
 energy_balance_type
 Indicates what type of energy balance should be constructed, default  EnergyBalanceType.useDefault. Valid values: { EnergyBalanceType.useDefault  refer to property package for default balance type **EnergyBalanceType.none  exclude energy balances, EnergyBalanceType.enthalpyTotal  single enthalpy balance for material, EnergyBalanceType.enthalpyPhase  enthalpy balances for each phase, EnergyBalanceType.energyTotal  single energy balance for material, EnergyBalanceType.energyPhase  energy balances for each phase.}
 momentum_balance_type
 Indicates what type of momentum balance should be constructed, default  MomentumBalanceType.pressureTotal. Valid values: { MomentumBalanceType.none  exclude momentum balances, MomentumBalanceType.pressureTotal  single pressure balance for material, MomentumBalanceType.pressurePhase  pressure balances for each phase, MomentumBalanceType.momentumTotal  single momentum balance for material, MomentumBalanceType.momentumPhase  momentum balances for each phase.}
 has_heat_transfer
 Indicates whether terms for heat transfer should be constructed, default  False. Valid values: { True  include heat transfer terms, False  exclude heat transfer terms.}
 has_pressure_change
 Indicates whether terms for pressure change should be constructed, default  False. Valid values: { True  include pressure change terms, False  exclude pressure change terms.}
 has_equilibrium_reactions
 Indicates whether terms for equilibrium controlled reactions should be constructed, default  True. Valid values: { True  include equilibrium reaction terms, False  exclude equilibrium reaction terms.}
 has_phase_equilibrium
 Indicates whether terms for phase equilibrium should be constructed, default = False. Valid values: { True  include phase equilibrium terms False  exclude phase equilibrium terms.}
 has_heat_of_reaction
 Indicates whether terms for heat of reaction terms should be constructed, default  False. Valid values: { True  include heat of reaction terms, False  exclude heat of reaction terms.}
 property_package
 Property parameter object used to define property calculations, default  useDefault. Valid values: { useDefault  use default package from parent model or flowsheet, PhysicalParameterObject  a PhysicalParameterBlock object.}
 property_package_args
 A ConfigBlock with arguments to be passed to a property block(s) and used when constructing these, default  None. Valid values: { see property package for documentation.}
 reaction_package
 Reaction parameter object used to define reaction calculations, default  None. Valid values: { None  no reaction package, ReactionParameterBlock  a ReactionParameterBlock object.}
 reaction_package_args
 A ConfigBlock with arguments to be passed to a reaction block(s) and used when constructing these, default  None. Valid values: { see reaction package for documentation.}
 initialize (dict) â€“ ProcessBlockData config for individual elements. Keys are BlockData indexes and values are dictionaries described under the â€śdefaultâ€ť argument above.
 idx_map (function) â€“ Function to take the index of a BlockData element and return the index in the initialize dict from which to read arguments. This can be provided to overide the default behavior of matching the BlockData index exactly to the index in initialize.
Returns: (CSTR) New instance
Equilibrium ReactorÂ¶
The IDAES Equilibrium reactor model represents a unit operation where a material stream undergoes some chemical reaction(s) to reach an equilibrium state. This model is for systems with reaction with equilibrium coefficients  for Gibbs energy minimization see Gibbs reactor documentation.
Degrees of FreedomÂ¶
Equilibrium reactors generally have 1 degree of freedom.
Typical fixed variables are:
 reactor heat duty (has_heat_transfer = True only).
Model StructureÂ¶
The core Equilibrium reactor unit model consists of a single ControlVolume0D
(named control_volume
) with one Inlet Port (named inlet
) and one Outlet Port (named outlet
).
Additional ConstraintsÂ¶
Equilibrium reactors units write the following additional Constraints beyond those written by the Control Volume if rate controlled reactions are present.
where \(r_{t,r}\) is the rate of reaction for reaction \(r\) at time \(t\). This enforces equilibrium in any reversible rate controlled reactions which are present. Any nonreversible reaction that may be present will proceed to completion.
VariablesÂ¶
Equilibrium reactor units add the following additional Variables beyond those created by the Control Volume.
Variable  Name  Notes 

\(V_t\)  volume  If has_holdup = True this is a reference to control_volume.volume , otherwise a Var attached to the Unit Model 
\(Q_t\)  heat  Only if has_heat_transfer = True , reference to control_volume.heat 
EquilibriumReactor ClassÂ¶

class
idaes.unit_models.equilibrium_reactor.
EquilibriumReactor
(*args, **kwargs)Â¶ Parameters:  rule (function) â€“ A rule function or None. Default rule calls build().
 concrete (bool) â€“ If True, make this a toplevel model. Default  False.
 ctype (str) â€“ Pyomo ctype of the block. Default  â€śBlockâ€ť
 default (dict) â€“
Default ProcessBlockData config
 Keys
 dynamic
 Indicates whether this model will be dynamic or not, default = False. Equilibrium Reactors do not support dynamic behavior.
 has_holdup
 Indicates whether holdup terms should be constructed or not. default  False. Equilibrium reactors do not have defined volume, thus this must be False.
 material_balance_type
 Indicates what type of mass balance should be constructed, default  MaterialBalanceType.useDefault. Valid values: { MaterialBalanceType.useDefault  refer to property package for default balance type **MaterialBalanceType.none  exclude material balances, MaterialBalanceType.componentPhase  use phase component balances, MaterialBalanceType.componentTotal  use total component balances, MaterialBalanceType.elementTotal  use total element balances, MaterialBalanceType.total  use total material balance.}
 energy_balance_type
 Indicates what type of energy balance should be constructed, default  EnergyBalanceType.useDefault. Valid values: { EnergyBalanceType.useDefault  refer to property package for default balance type **EnergyBalanceType.none  exclude energy balances, EnergyBalanceType.enthalpyTotal  single enthalpy balance for material, EnergyBalanceType.enthalpyPhase  enthalpy balances for each phase, EnergyBalanceType.energyTotal  single energy balance for material, EnergyBalanceType.energyPhase  energy balances for each phase.}
 momentum_balance_type
 Indicates what type of momentum balance should be constructed, default  MomentumBalanceType.pressureTotal. Valid values: { MomentumBalanceType.none  exclude momentum balances, MomentumBalanceType.pressureTotal  single pressure balance for material, MomentumBalanceType.pressurePhase  pressure balances for each phase, MomentumBalanceType.momentumTotal  single momentum balance for material, MomentumBalanceType.momentumPhase  momentum balances for each phase.}
 has_rate_reactions
 Indicates whether terms for rate controlled reactions should be constructed, along with constraints equating these to zero, default  True. Valid values: { True  include rate reaction terms, False  exclude rate reaction terms.}
 has_equilibrium_reactions
 Indicates whether terms for equilibrium controlled reactions should be constructed, default  True. Valid values: { True  include equilibrium reaction terms, False  exclude equilibrium reaction terms.}
 has_phase_equilibrium
 Indicates whether terms for phase equilibrium should be constructed, default  True. Valid values: { True  include phase equilibrium term, False  exclude phase equlibirum terms.}
 has_heat_transfer
 Indicates whether terms for heat transfer should be constructed, default  False. Valid values: { True  include heat transfer terms, False  exclude heat transfer terms.}
 has_heat_of_reaction
 Indicates whether terms for heat of reaction terms should be constructed, default  False. Valid values: { True  include heat of reaction terms, False  exclude heat of reaction terms.}
 has_pressure_change
 Indicates whether terms for pressure change should be constructed, default  False. Valid values: { True  include pressure change terms, False  exclude pressure change terms.}
 property_package
 Property parameter object used to define property calculations, default  useDefault. Valid values: { useDefault  use default package from parent model or flowsheet, PhysicalParameterObject  a PhysicalParameterBlock object.}
 property_package_args
 A ConfigBlock with arguments to be passed to a property block(s) and used when constructing these, default  None. Valid values: { see property package for documentation.}
 reaction_package
 Reaction parameter object used to define reaction calculations, default  None. Valid values: { None  no reaction package, ReactionParameterBlock  a ReactionParameterBlock object.}
 reaction_package_args
 A ConfigBlock with arguments to be passed to a reaction block(s) and used when constructing these, default  None. Valid values: { see reaction package for documentation.}
 initialize (dict) â€“ ProcessBlockData config for individual elements. Keys are BlockData indexes and values are dictionaries described under the â€śdefaultâ€ť argument above.
 idx_map (function) â€“ Function to take the index of a BlockData element and return the index in the initialize dict from which to read arguments. This can be provided to overide the default behavior of matching the BlockData index exactly to the index in initialize.
Returns: (EquilibriumReactor) New instance
Feed BlockÂ¶
Feed Blocks are used to represent sources of material in Flowsheets. Feed blocks do not calculate phase equilibrium of the feed stream, and the composition of the material in the outlet stream will be exactly as specified in the input. For applications where the users wishes the outlet stream to be in phase equilibrium, see the Feed_Flash unit model.
Degrees of FreedomÂ¶
The degrees of freedom of Feed blocks depends on the property package being used and the number of state variables necessary to fully define the system. Users should refer to documentation on the property package they are using.
Model StructureÂ¶
Feed Blocks consists of a single StateBlock (named properties), each with one Outlet Port (named outlet). Feed Blocks also contain References to the state variables defined within the StateBlock
Additional ConstraintsÂ¶
Feed Blocks write no additional constraints to the model.
VariablesÂ¶
Feed blocks add no additional Variables.
Feed ClassÂ¶

class
idaes.unit_models.feed.
Feed
(*args, **kwargs)Â¶ Parameters:  rule (function) â€“ A rule function or None. Default rule calls build().
 concrete (bool) â€“ If True, make this a toplevel model. Default  False.
 ctype (str) â€“ Pyomo ctype of the block. Default  â€śBlockâ€ť
 default (dict) â€“
Default ProcessBlockData config
 Keys
 dynamic
 Indicates whether this model will be dynamic or not, default = False. Feed blocks are always steadystate.
 has_holdup
 Feed blocks do not contain holdup, thus this must be False.
 property_package
 Property parameter object used to define property calculations, default  useDefault. Valid values: { useDefault  use default package from parent model or flowsheet, PhysicalParameterObject  a PhysicalParameterBlock object.}
 property_package_args
 A ConfigBlock with arguments to be passed to a property block(s) and used when constructing these, default  None. Valid values: { see property package for documentation.}
 initialize (dict) â€“ ProcessBlockData config for individual elements. Keys are BlockData indexes and values are dictionaries described under the â€śdefaultâ€ť argument above.
 idx_map (function) â€“ Function to take the index of a BlockData element and return the index in the initialize dict from which to read arguments. This can be provided to overide the default behavior of matching the BlockData index exactly to the index in initialize.
Returns: (Feed) New instance
FeedData ClassÂ¶

class
idaes.unit_models.feed.
FeedData
(component)[source]Â¶ Standard Feed Block Class

initialize
(state_args={}, outlvl=0, solver='ipopt', optarg={'tol': 1e06})[source]Â¶ This method calls the initialization method of the state block.
Keyword Arguments:  state_args â€“ a dict of arguments to be passed to the property package(s) to provide an initial state for initialization (see documentation of the specific property package) (default = {}).
 outlvl â€“
sets output level of initialisation routine
 0 = no output (default)
 1 = return solver state for each step in routine
 2 = return solver state for each step in subroutines
 3 = include solver output infomation (tee=True)
 optarg â€“ solver options dictionary object (default={â€tolâ€™: 1e6})
 solver â€“ str indicating which solver to use during initialization (default = â€ipoptâ€™)
Returns: None

Feed Block with FlashÂ¶
Feed Blocks are used to represent sources of material in Flowsheets. In some cases, users may have a situation where a feed stream may be in a multiphase state, but may not know the full details of the equilibrium state. The IDAES Feed Block with Flash (FeedFlash) allows users to define a feed block where the outlet is in phase equilibrium based on calculations from the chosen property package and a sufficient set of state variables prior to being passed to the first unit operation. The phase equilibrium is performed assuming an isobaric and isothermal flash operation.
A Feed Block with Flash is only required in cases where the feed may be in phase equilibrium AND the chosen property package uses a state definition that includes phase separations. Some property packages support phase equilibrium, but use a state definition that involves only total flows  in these cases a flash calculation is performed at the inlet of every unit and thus it is not necessary to perform a flash calculation at the feed block.
Degrees of FreedomÂ¶
The degrees of freedom of FeedFlash blocks depends on the property package being used and the number of state variables necessary to fully define the system. Users should refer to documentation on the property package they are using.
Model StructureÂ¶
FeedFlash Blocks contain a single ControlVolume0D
(named control_volume
) with one Outlet Port (named outlet
). FeedFlash Blocks also contain References to the state variables defined within the inlet StateBlock of the ControlVolume (representing the unflashed state of the feed).
FeedFlash Blocks do not write a set of energy balances within the Control Volume  instead a constraint is written which enforces an isothermal flash.
Additional ConstraintsÂ¶
The FeedFlash Block writes one additional constraint to enforce isothermal behavior.
where \(T_{in, t}\) and \(T_{out, t}\) are the temperatures of the material before and after the flash operation.
VariablesÂ¶
FeedFlash blocks add no additional Variables.
FeedFlash ClassÂ¶

class
idaes.unit_models.feed_flash.
FeedFlash
(*args, **kwargs)Â¶ Parameters:  rule (function) â€“ A rule function or None. Default rule calls build().
 concrete (bool) â€“ If True, make this a toplevel model. Default  False.
 ctype (str) â€“ Pyomo ctype of the block. Default  â€śBlockâ€ť
 default (dict) â€“
Default ProcessBlockData config
 Keys
 dynamic
 Feed units do not support dynamic behavior.
 has_holdup
 Feed units do not have defined volume, thus this must be False.
 material_balance_type
 Indicates what type of mass balance should be constructed, default  MaterialBalanceType.useDefault. Valid values: { MaterialBalanceType.useDefault  refer to property package for default balance type **MaterialBalanceType.none  exclude material balances, MaterialBalanceType.componentPhase  use phase component balances, MaterialBalanceType.componentTotal  use total component balances, MaterialBalanceType.elementTotal  use total element balances, MaterialBalanceType.total  use total material balance.}
 flash_type
 Indicates what type of flash operation should be used. default  FlashType.isothermal. Valid values: { FlashType.isothermal  specify temperature, FlashType.isenthalpic  specify enthalpy.}
 property_package
 Property parameter object used to define property calculations, default  useDefault. Valid values: { useDefault  use default package from parent model or flowsheet, PhysicalParameterObject  a PhysicalParameterBlock object.}
 property_package_args
 A ConfigBlock with arguments to be passed to a property block(s) and used when constructing these, default  None. Valid values: { see property package for documentation.}
 initialize (dict) â€“ ProcessBlockData config for individual elements. Keys are BlockData indexes and values are dictionaries described under the â€śdefaultâ€ť argument above.
 idx_map (function) â€“ Function to take the index of a BlockData element and return the index in the initialize dict from which to read arguments. This can be provided to overide the default behavior of matching the BlockData index exactly to the index in initialize.
Returns: (FeedFlash) New instance
Flash UnitÂ¶
The IDAES Flash model represents a unit operation where a single stream undergoes a flash separation into two phases. The Flash model supports mutile types of flash operations, including pressure changes and addition or removal of heat.
Degrees of FreedomÂ¶
Flash units generally have 2 degrees of freedom.
Typical fixed variables are:
 heat duty or outlet temperature (see note),
 pressure change or outlet pressure.
Note: When setting the outlet temeprature of a Flash unit, it is best to set control_volume.properties_out[t].temperature. Setting the temperature in one of the outlet streams directly results in a much harder problme to solve, and may be degenerate or unbounded in some cases.
Model StructureÂ¶
The core Flash unit model consists of a single ControlVolume0DBlock (named control_volume) with one Inlet Port (named inlet) connected to a Separator unit model with two outlet Ports named â€vap_outletâ€™ and â€liq_outletâ€™. The Flash model utilizes the separator unit model in IDAES to split the outlets by phase flows to the liquid and vapor outlets respectively.
The Separator unit model supports both direct splitting of state variables and writting of full splitting constraints via the ideal_separation construction argument. Full details on the Separator unit model can be found in the documentation for that unit. To support direct splitting, the property package must use one of a specified set of state variables and support a certain set of property calacuations, as outlined in the table below.
State Variables  Required Properties 

Material flow and composition  
flow_mol & mole_frac  flow_mol_phase & mole_frac_phase 
flow_mol_phase & mole_frac_phase  flow_mol_phase & mole_frac_phase 
flow_mol_comp  flow_mol_phase_comp 
flow_mol_phase_comp  flow_mol_phase_comp 
flow_mass & mass_frac  flow_mass_phase & mass_frac_phase 
flow_mass_phase & mass_frac_phase  flow_mass_phase & mass_frac_phase 
flow_mass_comp  flow_mass_phase_comp 
flow_mass_phase_comp  flow_mass_phase_comp 
Energy state  
temperature  temperature 
enth_mol  enth_mol_phase 
enth_mol_phase  enth_mol_phase 
enth_mass  enth_mass_phase 
enth_mass_phase  enth_mass_phase 
Pressure state  
pressure  pressure 
Construction ArgumentsÂ¶
Flash units have the following construction arguments:
 property_package  property package to use when constructing Property Blocks (default = â€use_parent_valueâ€™). This is provided as a Property Parameter Block by the Flowsheet when creating the model. If a value is not provided, the Holdup Block will try to use the default property package if one is defined.
 property_package_args  set of arguments to be passed to the Property Blocks when they are created.
Additionally, Flash units have the following construction arguments which are passed to the Holdup Block for determining which terms to construct in the balance equations.
Argument  Default Value 

dynamic  False 
include_holdup  False 
material_balance_type  MaterialBalanceType.componentPhase 
energy_balance_type  EnergyBalanceType.enthalpyTotal 
momentum_balance_type  MomentumBalanceType.pressureTotal 
has_phase_equilibrium  True 
has_heat_transfer  True 
has_pressure_change  True 
Finally, Flash units also have the following arguments which are passed to the Separator block for determining how to split to twophase mixture.
Argument  Default Value 

ideal_separation  True 
energy_split_basis  EnergySplittingType.equal_temperature 
Additional ConstraintsÂ¶
Flash units write no additional Constraints beyond those written by the ControlVolume0DBlock and the Separator block.
VariablesÂ¶
Name  Notes 

heat_duty  Reference to control_volume.heat 
deltaP  Reference to control_volume.deltaP 
Flash ClassÂ¶

class
idaes.unit_models.flash.
Flash
(*args, **kwargs)Â¶ Parameters:  rule (function) â€“ A rule function or None. Default rule calls build().
 concrete (bool) â€“ If True, make this a toplevel model. Default  False.
 ctype (str) â€“ Pyomo ctype of the block. Default  â€śBlockâ€ť
 default (dict) â€“
Default ProcessBlockData config
 Keys
 dynamic
 Indicates whether this model will be dynamic or not, default = False. Flash units do not support dynamic behavior.
 has_holdup
 Indicates whether holdup terms should be constructed or not. default  False. Flash units do not have defined volume, thus this must be False.
 material_balance_type
 Indicates what type of mass balance should be constructed, default  MaterialBalanceType.useDefault. Valid values: { MaterialBalanceType.useDefault  refer to property package for default balance type **MaterialBalanceType.none  exclude material balances, MaterialBalanceType.componentPhase  use phase component balances, MaterialBalanceType.componentTotal  use total component balances, MaterialBalanceType.elementTotal  use total element balances, MaterialBalanceType.total  use total material balance.}
 energy_balance_type
 Indicates what type of energy balance should be constructed, default  EnergyBalanceType.useDefault. Valid values: { EnergyBalanceType.useDefault  refer to property package for default balance type **EnergyBalanceType.none  exclude energy balances, EnergyBalanceType.enthalpyTotal  single enthalpy balance for material, EnergyBalanceType.enthalpyPhase  enthalpy balances for each phase, EnergyBalanceType.energyTotal  single energy balance for material, EnergyBalanceType.energyPhase  energy balances for each phase.}
 momentum_balance_type
 Indicates what type of momentum balance should be constructed, default  MomentumBalanceType.pressureTotal. Valid values: { MomentumBalanceType.none  exclude momentum balances, MomentumBalanceType.pressureTotal  single pressure balance for material, MomentumBalanceType.pressurePhase  pressure balances for each phase, MomentumBalanceType.momentumTotal  single momentum balance for material, MomentumBalanceType.momentumPhase  momentum balances for each phase.}
 energy_split_basis
 Argument indicating basis to use for splitting energy this is not used for when ideal_separation == True. default  EnergySplittingType.equal_temperature. Valid values: { EnergySplittingType.equal_temperature  outlet temperatures equal inlet EnergySplittingType.equal_molar_enthalpy  oulet molar enthalpies equal inlet, EnergySplittingType.enthalpy_split  apply split fractions to enthalpy flows.}
 ideal_separation
 Argument indicating whether ideal splitting should be used. Ideal splitting assumes perfect separation of material, and attempts to avoid duplication of StateBlocks by directly partitioning outlet flows to ports, default  True. Valid values: { True  use ideal splitting methods. Cannot be combined with has_phase_equilibrium = True, False  use explicit splitting equations with split fractions.}
 has_heat_transfer
 Indicates whether terms for heat transfer should be constructed, default  False. Valid values: { True  include heat transfer terms, False  exclude heat transfer terms.}
 has_pressure_change
 Indicates whether terms for pressure change should be constructed, default  True. Valid values: { True  include pressure change terms, False  exclude pressure change terms.}
 property_package
 Property parameter object used to define property calculations, default  useDefault. Valid values: { useDefault  use default package from parent model or flowsheet, PropertyParameterObject  a PropertyParameterBlock object.}
 property_package_args
 A ConfigBlock with arguments to be passed to a property block(s) and used when constructing these, default  None. Valid values: { see property package for documentation.}
 initialize (dict) â€“ ProcessBlockData config for individual elements. Keys are BlockData indexes and values are dictionaries described under the â€śdefaultâ€ť argument above.
 idx_map (function) â€“ Function to take the index of a BlockData element and return the index in the initialize dict from which to read arguments. This can be provided to overide the default behavior of matching the BlockData index exactly to the index in initialize.
Returns: (Flash) New instance
Gibbs ReactorÂ¶
The IDAES Gibbs reactor model represents a unit operation where a material stream undergoes some set of reactions such that the Gibbs energy of the resulting mixture is minimized. Gibbs reactors rely on conservation of individual elements within the system, and thus require element balances, and make use of Lagrange multipliers to find the minimum Gibbs energy state of the system.
Degrees of FreedomÂ¶
Gibbs reactors generally have between 0 and 2 degrees of freedom, depending on construction arguments.
Typical fixed variables are:
 reactor heat duty (has_heat_transfer = True only).
 reactor pressure change (has_pressure_change = True only).
Model StructureÂ¶
The core Gibbs reactor unit model consists of a single ControlVolume0DBlock (named control_volume) with one Inlet Port (named inlet) and one Outlet Port (named outlet).
VariablesÂ¶
Gibbs reactor units add the following additional Variables beyond those created by the Control Volume Block.
Variable Name  Symbol  Notes 

lagrange_mult  \(L_{t,e}\)  Lagrange multipliers 
heat_duty  \(Q_t\)  Only if has_heat_transfer = True, reference 
deltaP  \(\Delta P_t\)  Only if has_pressure_change = True, reference 
ConstraintsÂ¶
Gibbs reactor models write the following additional constraints to calculate the state that corresponds to the minimum Gibbs energy of the system.
gibbs_minimization(time, phase, component):
where \(g_{partial,t,j}\) is the partial molar Gibbs energy of component \(j\) at time \(t\), \(L_{t,e}\) is the Lagrange multiplier for element \(e\) at time \(t\) and \(\alpha_{j,e}\) is the number of moles of element \(e\) in one mole of component \(j\). \(g_{partial,t,j}\) and \(\alpha_{j,e}\) come from the outlet StateBlock.
GibbsReactor ClassÂ¶

class
idaes.unit_models.gibbs_reactor.
GibbsReactor
(*args, **kwargs)Â¶ Parameters:  rule (function) â€“ A rule function or None. Default rule calls build().
 concrete (bool) â€“ If True, make this a toplevel model. Default  False.
 ctype (str) â€“ Pyomo ctype of the block. Default  â€śBlockâ€ť
 default (dict) â€“
Default ProcessBlockData config
 Keys
 dynamic
 Gibbs reactors do not support dynamic models, thus this must be False.
 has_holdup
 Gibbs reactors do not have defined volume, thus this must be False.
 energy_balance_type
 Indicates what type of energy balance should be constructed, default  EnergyBalanceType.useDefault. Valid values: { EnergyBalanceType.useDefault  refer to property package for default balance type **EnergyBalanceType.none  exclude energy balances, EnergyBalanceType.enthalpyTotal  single enthalpy balance for material, EnergyBalanceType.enthalpyPhase  enthalpy balances for each phase, EnergyBalanceType.energyTotal  single energy balance for material, EnergyBalanceType.energyPhase  energy balances for each phase.}
 momentum_balance_type
 Indicates what type of momentum balance should be constructed, default  MomentumBalanceType.pressureTotal. Valid values: { MomentumBalanceType.none  exclude momentum balances, MomentumBalanceType.pressureTotal  single pressure balance for material, MomentumBalanceType.pressurePhase  pressure balances for each phase, MomentumBalanceType.momentumTotal  single momentum balance for material, MomentumBalanceType.momentumPhase  momentum balances for each phase.}
 has_heat_transfer
 Indicates whether terms for heat transfer should be constructed, default  False. Valid values: { True  include heat transfer terms, False  exclude heat transfer terms.}
 has_pressure_change
 Indicates whether terms for pressure change should be constructed, default  False. Valid values: { True  include pressure change terms, False  exclude pressure change terms.}
 property_package
 Property parameter object used to define property calculations, default  useDefault. Valid values: { useDefault  use default package from parent model or flowsheet, PropertyParameterObject  a PropertyParameterBlock object.}
 property_package_args
 A ConfigBlock with arguments to be passed to a property block(s) and used when constructing these, default  None. Valid values: { see property package for documentation.}
 initialize (dict) â€“ ProcessBlockData config for individual elements. Keys are BlockData indexes and values are dictionaries described under the â€śdefaultâ€ť argument above.
 idx_map (function) â€“ Function to take the index of a BlockData element and return the index in the initialize dict from which to read arguments. This can be provided to overide the default behavior of matching the BlockData index exactly to the index in initialize.
Returns: (GibbsReactor) New instance
GibbsReactorData ClassÂ¶

class
idaes.unit_models.gibbs_reactor.
GibbsReactorData
(component)[source]Â¶ Standard Gibbs Reactor Unit Model Class
This model assume all possible reactions reach equilibrium such that the system partial molar Gibbs free energy is minimized. Since some species mole flow rate might be very small, the natural log of the species molar flow rate is used. Instead of specifying the system Gibbs free energy as an objective function, the equations for zero partial derivatives of the grand function with Lagrangian multiple terms with repect to product species mole flow rates and the multiples are specified as constraints.
HeaterÂ¶
The Heater model is a simple 0D model that adds or removes heat from a material stream.
ExampleÂ¶
import pyomo.environ as pe # Pyomo environment
from idaes.core import FlowsheetBlock, StateBlock
from idaes.unit_models import Heater
from idaes.property_models import iapws95
# Create an empty flowsheet and steam property parameter block.
model = pe.ConcreteModel()
model.fs = FlowsheetBlock(default={"dynamic": False})
model.fs.properties = iapws95.Iapws95ParameterBlock()
# Add a Heater model to the flowsheet.
model.fs.heater = Heater(default={"property_package": model.fs.properties})
# Setup the heater model by fixing the inputs and heat duty
model.fs.heater.inlet[:].enth_mol.fix(4000)
model.fs.heater.inlet[:].flow_mol.fix(100)
model.fs.heater.inlet[:].pressure.fix(101325)
model.fs.heater.heat_duty[:].fix(100*20000)
# Initialize the model.
model.fs.heater.initialize()
Degrees of FreedomÂ¶
Aside from the inlet conditions, a heater model usually has one degree of freedom, which is the heat duty.
Model StructureÂ¶
A heater model contains one ControlVolume0DBlock block.
VariablesÂ¶
The heat_duty
variable is a reference to control_volume.heat
.
ConstraintsÂ¶
A heater model contains no additional constraints beyond what are contained in
a ControlVolume0DBlock
model.
Heater ClassÂ¶

class
idaes.unit_models.heater.
Heater
(*args, **kwargs)Â¶ Simple 0D heater/cooler model.
Parameters:  rule (function) â€“ A rule function or None. Default rule calls build().
 concrete (bool) â€“ If True, make this a toplevel model. Default  False.
 ctype (str) â€“ Pyomo ctype of the block. Default  â€śBlockâ€ť
 default (dict) â€“
Default ProcessBlockData config
 Keys
 dynamic
 Indicates whether this model will be dynamic or not, default = useDefault. Valid values: { useDefault  get flag from parent (default = False), True  set as a dynamic model, False  set as a steadystate model.}
 has_holdup
 Indicates whether holdup terms should be constructed or not. Must be True if dynamic = True, default  False. Valid values: { True  construct holdup terms, False  do not construct holdup terms}
 material_balance_type
 Indicates what type of mass balance should be constructed, default  MaterialBalanceType.useDefault. Valid values: { MaterialBalanceType.useDefault  refer to property package for default balance type **MaterialBalanceType.none  exclude material balances, MaterialBalanceType.componentPhase  use phase component balances, MaterialBalanceType.componentTotal  use total component balances, MaterialBalanceType.elementTotal  use total element balances, MaterialBalanceType.total  use total material balance.}
 energy_balance_type
 Indicates what type of energy balance should be constructed, default  EnergyBalanceType.useDefault. Valid values: { EnergyBalanceType.useDefault  refer to property package for default balance type **EnergyBalanceType.none  exclude energy balances, EnergyBalanceType.enthalpyTotal  single enthalpy balance for material, EnergyBalanceType.enthalpyPhase  enthalpy balances for each phase, EnergyBalanceType.energyTotal  single energy balance for material, EnergyBalanceType.energyPhase  energy balances for each phase.}
 momentum_balance_type
 Indicates what type of momentum balance should be constructed, default  MomentumBalanceType.pressureTotal. Valid values: { MomentumBalanceType.none  exclude momentum balances, MomentumBalanceType.pressureTotal  single pressure balance for material, MomentumBalanceType.pressurePhase  pressure balances for each phase, MomentumBalanceType.momentumTotal  single momentum balance for material, MomentumBalanceType.momentumPhase  momentum balances for each phase.}
 has_phase_equilibrium
 Indicates whether terms for phase equilibrium should be constructed, default = False. Valid values: { True  include phase equilibrium terms False  exclude phase equilibrium terms.}
 has_pressure_change
 Indicates whether terms for pressure change should be constructed, default  False. Valid values: { True  include pressure change terms, False  exclude pressure change terms.}
 property_package
 Property parameter object used to define property calculations, default  useDefault. Valid values: { useDefault  use default package from parent model or flowsheet, PropertyParameterObject  a PropertyParameterBlock object.}
 property_package_args
 A ConfigBlock with arguments to be passed to a property block(s) and used when constructing these, default  None. Valid values: { see property package for documentation.}
 initialize (dict) â€“ ProcessBlockData config for individual elements. Keys are BlockData indexes and values are dictionaries described under the â€śdefaultâ€ť argument above.
 idx_map (function) â€“ Function to take the index of a BlockData element and return the index in the initialize dict from which to read arguments. This can be provided to overide the default behavior of matching the BlockData index exactly to the index in initialize.
Returns: (Heater) New instance
HeatExchanger (0D)Â¶
The HeatExchanger model can be imported from idaes.unit_models
,
while additional rules and utility functions can be imported from
idaes.unit_models.heat_exchanger
.
ExampleÂ¶
The example below demonstrates how to initialize the HeatExchanger model, and override the default temperature difference calculation.
import pyomo.environ as pe # Pyomo environment
from idaes.core import FlowsheetBlock, StateBlock
from idaes.unit_models import HeatExchanger
from idaes.unit_models.heat_exchanger import delta_temperature_amtd_callback
from idaes.property_models import iapws95
# Create an empty flowsheet and steam property parameter block.
model = pe.ConcreteModel()
model.fs = FlowsheetBlock(default={"dynamic": False})
model.fs.properties = iapws95.Iapws95ParameterBlock()
# Add a Heater model to the flowsheet.
model.fs.heat_exchanger = HeatExchanger(default={
"delta_temperature_callback":delta_temperature_amtd_callback,
"shell":{"property_package": model.fs.properties},
"tube":{"property_package": model.fs.properties}})
model.fs.heat_exchanger.area.fix(1000)
model.fs.heat_exchanger.overall_heat_transfer_coefficient[0].fix(100)
model.fs.heat_exchanger.shell_inlet.flow_mol.fix(100)
model.fs.heat_exchanger.shell_inlet.pressure.fix(101325)
model.fs.heat_exchanger.shell_inlet.enth_mol.fix(4000)
model.fs.heat_exchanger.tube_inlet.flow_mol.fix(100)
model.fs.heat_exchanger.tube_inlet.pressure.fix(101325)
model.fs.heat_exchanger.tube_inlet.enth_mol.fix(3000)
# Initialize the model
model.fs.heat_exchanger.initialize()
Degrees of FreedomÂ¶
Aside from the inlet conditions, a heat exchanger model usually has two degrees of freedom, which can be fixed for it to be fully specified. Things that are frequently fixed are two of:
 heat transfer area,
 heat transfer coefficient, or
 temperature approach.
The user may also provide constants to calculate the heat transfer coefficient.
Model StructureÂ¶
The HeatExchanger
model contains two ControlVolume0DBlock
blocks. By default the
hot side is named shell
and the cold side is named tube
. These names are configurable.
The sign convention is that duty is positive for heat flowing from the hot side to the cold
side. Aside from the sign convention there is no requirement that the hot side be hotter
than the cold side.
The control volumes are configured the same as the ControlVolume0DBlock
in the
Heater model. The HeatExchanger
model contains additional
constraints that calculate the amount of heat transferred from the hot side to the cold side.
The HeatExchanger
has two inlet ports and two outlet ports. By default these are
shell_inlet
, tube_inlet
, shell_outlet
, and tube_outlet
. If the user
supplies different hot and cold side names the inlet and outlets are named accordingly.
VariablesÂ¶
Variable  Symbol  Index Sets  Doc 

heat_duty  \(Q\)  t  Heat transferred from hot side to the cold side 
area  \(A\)  None  Heat transfer area 
heat_transfer_coefficient  \(U\)  t  Heat transfer coefficient 
delta_temperature  \(\Delta T\)  t  Temperature difference, defaults to LMTD 
Note: delta_temperature
may be either a variable or expression depending on the callback used. If the specified cold side is hotter
than the specified hot side this value will be negative.
ConstraintsÂ¶
The default constants can be overridden by providing alternative rules for the heat transfer equation, temperature difference, and heat transfer coefficient. The section describes the default constraints.
Heat transfer from shell to tube:
Temperature difference is an expression:
The heat transfer coefficient is a variable with no associated constraints by default.
Class DocumentationÂ¶
Note
The hot_side_config
and cold_side_config
can also be supplied using the name of
the hot and cold sides (shell
and tube
by default) as in the example.

class
idaes.unit_models.heat_exchanger.
HeatExchanger
(*args, **kwargs)Â¶ Simple 0D heat exchanger model.
Parameters:  rule (function) â€“ A rule function or None. Default rule calls build().
 concrete (bool) â€“ If True, make this a toplevel model. Default  False.
 ctype (str) â€“ Pyomo ctype of the block. Default  â€śBlockâ€ť
 default (dict) â€“
Default ProcessBlockData config
 Keys
 dynamic
 Indicates whether this model will be dynamic or not, default = useDefault. Valid values: { useDefault  get flag from parent (default = False), True  set as a dynamic model, False  set as a steadystate model.}
 has_holdup
 Indicates whether holdup terms should be constructed or not. Must be True if dynamic = True, default  False. Valid values: { True  construct holdup terms, False  do not construct holdup terms}
 hot_side_name
 Hot side name, sets control volume and inlet and outlet names
 cold_side_name
 Cold side name, sets control volume and inlet and outlet names
 hot_side_config
 A config block used to construct the hot side control
volume. This config can be given by the hot side name
instead of hot_side_config.
 material_balance_type
 Indicates what type of mass balance should be constructed, default  MaterialBalanceType.useDefault. Valid values: { MaterialBalanceType.useDefault  refer to property package for default balance type **MaterialBalanceType.none  exclude material balances, MaterialBalanceType.componentPhase  use phase component balances, MaterialBalanceType.componentTotal  use total component balances, MaterialBalanceType.elementTotal  use total element balances, MaterialBalanceType.total  use total material balance.}
 energy_balance_type
 Indicates what type of energy balance should be constructed, default  EnergyBalanceType.useDefault. Valid values: { EnergyBalanceType.useDefault  refer to property package for default balance type **EnergyBalanceType.none  exclude energy balances, EnergyBalanceType.enthalpyTotal  single enthalpy balance for material, EnergyBalanceType.enthalpyPhase  enthalpy balances for each phase, EnergyBalanceType.energyTotal  single energy balance for material, EnergyBalanceType.energyPhase  energy balances for each phase.}
 momentum_balance_type
 Indicates what type of momentum balance should be constructed, default  MomentumBalanceType.pressureTotal. Valid values: { MomentumBalanceType.none  exclude momentum balances, MomentumBalanceType.pressureTotal  single pressure balance for material, MomentumBalanceType.pressurePhase  pressure balances for each phase, MomentumBalanceType.momentumTotal  single momentum balance for material, MomentumBalanceType.momentumPhase  momentum balances for each phase.}
 has_phase_equilibrium
 Indicates whether terms for phase equilibrium should be constructed, default = False. Valid values: { True  include phase equilibrium terms False  exclude phase equilibrium terms.}
 has_pressure_change
 Indicates whether terms for pressure change should be constructed, default  False. Valid values: { True  include pressure change terms, False  exclude pressure change terms.}
 property_package
 Property parameter object used to define property calculations, default  useDefault. Valid values: { useDefault  use default package from parent model or flowsheet, PropertyParameterObject  a PropertyParameterBlock object.}
 property_package_args
 A ConfigBlock with arguments to be passed to a property block(s) and used when constructing these, default  None. Valid values: { see property package for documentation.}
 cold_side_config
 A config block used to construct the cold side control
volume. This config can be given by the cold side name
instead of cold_side_config.
 material_balance_type
 Indicates what type of mass balance should be constructed, default  MaterialBalanceType.useDefault. Valid values: { MaterialBalanceType.useDefault  refer to property package for default balance type **MaterialBalanceType.none  exclude material balances, MaterialBalanceType.componentPhase  use phase component balances, MaterialBalanceType.componentTotal  use total component balances, MaterialBalanceType.elementTotal  use total element balances, MaterialBalanceType.total  use total material balance.}
 energy_balance_type
 Indicates what type of energy balance should be constructed, default  EnergyBalanceType.useDefault. Valid values: { EnergyBalanceType.useDefault  refer to property package for default balance type **EnergyBalanceType.none  exclude energy balances, EnergyBalanceType.enthalpyTotal  single enthalpy balance for material, EnergyBalanceType.enthalpyPhase  enthalpy balances for each phase, EnergyBalanceType.energyTotal  single energy balance for material, EnergyBalanceType.energyPhase  energy balances for each phase.}
 momentum_balance_type
 Indicates what type of momentum balance should be constructed, default  MomentumBalanceType.pressureTotal. Valid values: { MomentumBalanceType.none  exclude momentum balances, MomentumBalanceType.pressureTotal  single pressure balance for material, MomentumBalanceType.pressurePhase  pressure balances for each phase, MomentumBalanceType.momentumTotal  single momentum balance for material, MomentumBalanceType.momentumPhase  momentum balances for each phase.}
 has_phase_equilibrium
 Indicates whether terms for phase equilibrium should be constructed, default = False. Valid values: { True  include phase equilibrium terms False  exclude phase equilibrium terms.}
 has_pressure_change
 Indicates whether terms for pressure change should be constructed, default  False. Valid values: { True  include pressure change terms, False  exclude pressure change terms.}
 property_package
 Property parameter object used to define property calculations, default  useDefault. Valid values: { useDefault  use default package from parent model or flowsheet, PropertyParameterObject  a PropertyParameterBlock object.}
 property_package_args
 A ConfigBlock with arguments to be passed to a property block(s) and used when constructing these, default  None. Valid values: { see property package for documentation.}
 delta_temperature_callback
 Callback for for temperature difference calculations
 flow_pattern
 Heat exchanger flow pattern, default  HeatExchangerFlowPattern.countercurrent. Valid values: { HeatExchangerFlowPattern.countercurrent  countercurrent flow, HeatExchangerFlowPattern.cocurrent  cocurrent flow, HeatExchangerFlowPattern.crossflow  cross flow, factor times countercurrent temperature difference.}
 initialize (dict) â€“ ProcessBlockData config for individual elements. Keys are BlockData indexes and values are dictionaries described under the â€śdefaultâ€ť argument above.
 idx_map (function) â€“ Function to take the index of a BlockData element and return the index in the initialize dict from which to read arguments. This can be provided to overide the default behavior of matching the BlockData index exactly to the index in initialize.
Returns: (HeatExchanger) New instance

class
idaes.unit_models.heat_exchanger.
HeatExchangerData
(component)[source]Â¶ Simple 0D heat exchange unit. Unit model to transfer heat from one material to another.

initialize
(state_args_1=None, state_args_2=None, outlvl=0, solver='ipopt', optarg={'tol': 1e06}, duty=1000)[source]Â¶ Heat exchanger initialization method.
Parameters:  state_args_1 â€“ a dict of arguments to be passed to the property initialization for side_1 (see documentation of the specific property package) (default = {}).
 state_args_2 â€“ a dict of arguments to be passed to the property initialization for side_2 (see documentation of the specific property package) (default = {}).
 outlvl â€“ sets output level of initialisation routine * 0 = no output (default) * 1 = return solver state for each step in routine * 2 = return solver state for each step in subroutines * 3 = include solver output infomation (tee=True)
 optarg â€“ solver options dictionary object (default={â€tolâ€™: 1e6})
 solver â€“ str indicating which solver to use during initialization (default = â€ipoptâ€™)
 duty â€“ an initial guess for the amount of heat transfered (default = 10000)
Returns: None

set_scaling_factor_energy
(f)[source]Â¶ This function sets scaling_factor_energy for both side_1 and side_2. This factor multiplies the energy balance and heat transfer equations in the heat exchnager. The value of this factor should be about 1/(expected heat duty).
Parameters: f â€“ Energy balance scaling factor

CallbacksÂ¶
A selection of functions for constructing the delta_temperature
variable or
expression are provided in the idaes.unit_models.heat_exchanger
module.
The user may also provide their own function. These callbacks should all take
one argument (the HeatExchanger block). With the block argument, the function
can add any additional variables, constraints, and expressions needed. The only
requirement is that either a variable or expression called delta_temperature
must be added to the block.
Defined Callbacks for the delta_temperature_callback
OptionÂ¶
These callbacks provide expressions for the temperature difference used in the heat transfer equations.

idaes.unit_models.heat_exchanger.
delta_temperature_lmtd_callback
(b)[source]Â¶ This is a callback for a temperaure difference expression to calculate \(\Delta T\) in the heat exchanger model using logmean temperature difference (LMTD). It can be supplied to â€śdelta_temperature_callbackâ€ť HeatExchanger configuration option.

idaes.unit_models.heat_exchanger.
delta_temperature_amtd_callback
(b)[source]Â¶ This is a callback for a temperaure difference expression to calculate \(\Delta T\) in the heat exchanger model using arithmeticmean temperature difference (AMTD). It can be supplied to â€śdelta_temperature_callbackâ€ť HeatExchanger configuration option.

idaes.unit_models.heat_exchanger.
delta_temperature_underwood_callback
(b)[source]Â¶ This is a callback for a temperaure difference expression to calculate \(\Delta T\) in the heat exchanger model using logmean temperature difference (LMTD) approximation given by Underwood (1970). It can be supplied to â€śdelta_temperature_callbackâ€ť HeatExchanger configuration option. This uses a cube root function that works with negative numbers returning the real negative root. This should always evaluate successfully.
Heat Exchangers (1D)Â¶
Heat Exchanger models represents a unit operation with two material streams which exchange heat. The IDAES 1D Heat Exchanger model is used for detailed modeling of heat exchanger units with variations in one spatial dimension. For a simpler representation of a heat exchanger unit see Heat Exchanger (0D).
Degrees of FreedomÂ¶
1D Heat Exchangers generally have 7 degrees of freedom.
Typical fixed variables are:
 shell length and diameter,
 tube length and diameter,
 number of tubes,
 heat transfer coefficients (at all spatial points) for both shell and tube sides.
Model StructureÂ¶
The core 1D Heat Exchanger Model unit model consists of two ControlVolume1DBlock Blocks (named shell and tube), each with one Inlet Port (named shell_inlet and tube_inlet) and one Outlet Port (named shell_outlet and tube_outlet).
Construction ArgumentsÂ¶
1D Heat Exchanger units have construction arguments specific to the shell side, tube side and for the unit as a whole.
Arguments that are applicable to the heat exchanger unit are as follows:
flow_type  indicates the flow arrangement within the unit to be modeled. Options are:
 â€cocurrentâ€™  (default) shell and tube both flow in the same direction (from x=0 to x=1)
 â€countercurrentâ€™  shell and tube flow in opposite directions (shell from x=0 to x=1 and tube from x=1 to x=0).
finite_elements  sets the number of finite elements to use when discretizing the spatial domains (default = 20). This is used for both shell and tube side domains.
collocation_points  sets the number of collocation points to use when discretizing the spatial domains (default = 5, collocation methods only). This is used for both shell and tube side domains.
 has_wall_conduction  option to enable a model for heat conduction across the tube wall:
 â€noneâ€™  0D wall model
 â€1Dâ€™  1D heat conduction equation along the thickness of the tube wall
 â€2Dâ€™  2D heat conduction equation along the length and thickness of the tube wall
Arguments that are applicable to the shell side:
 property_package  property package to use when constructing shell side Property Blocks (default = â€use_parent_valueâ€™). This is provided as a Physical Parameter Block by the Flowsheet when creating the model. If a value is not provided, the ControlVolume Block will try to use the default property package if one is defined.
 property_package_args  set of arguments to be passed to the shell side Property Blocks when they are created.
 transformation_method  argument to specify the DAE transformation method for the shell side; should be compatible with the Pyomo DAE TransformationFactory
 transformation_scheme  argument to specify the scheme to use for the selected DAE transformation method; should be compatible with the Pyomo DAE TransformationFactory
Arguments that are applicable to the tube side:
 property_package  property package to use when constructing tube side Property Blocks (default = â€use_parent_valueâ€™). This is provided as a Property Parameter Block by the Flowsheet when creating the model. If a value is not provided, the ControlVolume Block will try to use the default property package if one is defined.
 property_package_args  set of arguments to be passed to the tube side Property Blocks when they are created.
 transformation_method  argument to specify the DAE transformation method for the tube side; should be compatible with the Pyomo DAE TransformationFactory
 transformation_scheme  argument to specify the scheme to use for the selected DAE transformation method; should be compatible with the Pyomo DAE TransformationFactory
Additionally, 1D Heat Exchanger units have the following construction arguments which are passed to the ControlVolume1DBlock Block for determining which terms to construct in the balance equations for the shell and tube side.
Argument  Default Value 

dynamic  useDefault 
has_holdup  False 
material_balance_type  â€componentTotalâ€™ 
energy_balance_type  â€enthalpyTotalâ€™ 
momentum_balance_type  â€pressureTotalâ€™ 
has_phase_equilibrium  False 
has_heat_transfer  True 
has_pressure_change  False 
Additional ConstraintsÂ¶
1D Heat Exchanger models write the following additional Constraints to describe the heat transfer between the two sides of the heat exchanger. Firstly, the shell and tubeside heat transfer is calculated as:
where \(Q_{shell,t,x}\) is the shellside heat duty at point \(x\) and time \(t\), \(N_{tubes}\) \(D_{tube}\) are the number of and diameter of the tubes in the heat exchanger, \(U_{shell,t,x}\) is the shellside heat transfer coefficient, and \(T_{shell,t,x}\) and \(T_{wall,t,x}\) are the shellside and tube wall temperatures respectively.
where \(Q_{tube,t,x}\) is the tubeside heat duty at point \(x\) and time \(t\), \(U_{tube,t,x}\) is the tubeside heat transfer coefficient and \(T_{tube,t,x}\) is the tubeside temperature.
If a OD wall model is used for the tube wall conduction, the following constraint is implemented to connect the heat terms on the shell and tube side:
Finally, the following Constraints are written to describe the unit geometry:
where \(A_{shell}\) and \(A_{tube}\) are the shell and tube areas respectively and \(D_{shell}\) and \(D_{tube}\) are the shell and tube diameters.
VariablesÂ¶
1D Heat Exchanger units add the following additional Variables beyond those created by the ControlVolume1DBlock Block.
Variable  Name  Notes 

\(L_{shell}\)  shell_length  Reference to shell.length 
\(A_{shell}\)  shell_area  Reference to shell.area 
\(D_{shell}\)  d_shell  
\(L_{tube}\)  tube_length  Reference to tube.length 
\(A_{tube}\)  tube_area  Reference to tube.area 
\(D_{tube}\)  d_tube  
\(N_{tubes}\)  N_tubes  
\(T_{wall,t,x}\)  temperature_wall  
\(U_{shell,t,x}\)  shell_heat_transfer_coefficient  
\(U_{tube,t,x}\)  tube_heat_transfer_coefficient 
HeatExchanger1dClassÂ¶

class
idaes.unit_models.heat_exchanger_1D.
HeatExchanger1D
(*args, **kwargs)Â¶ Parameters:  rule (function) â€“ A rule function or None. Default rule calls build().
 concrete (bool) â€“ If True, make this a toplevel model. Default  False.
 ctype (str) â€“ Pyomo ctype of the block. Default  â€śBlockâ€ť
 default (dict) â€“
Default ProcessBlockData config
 Keys
 dynamic
 Indicates whether this model will be dynamic or not, default = useDefault. Valid values: { useDefault  get flag from parent (default = False), True  set as a dynamic model, False  set as a steadystate model.}
 has_holdup
 Indicates whether holdup terms should be constructed or not. Must be True if dynamic = True, default  False. Valid values: { True  construct holdup terms, False  do not construct holdup terms}
 shell_side
 shell side config arguments
 dynamic
 Indicates whether this model will be dynamic or not, default = useDefault. Valid values: { useDefault  get flag from parent (default = False), True  set as a dynamic model, False  set as a steadystate model.}
 has_holdup
 Indicates whether holdup terms should be constructed or not. Must be True if dynamic = True, default  False. Valid values: { True  construct holdup terms, False  do not construct holdup terms}
 material_balance_type
 Indicates what type of mass balance should be constructed, default  MaterialBalanceType.useDefault. Valid values: { MaterialBalanceType.useDefault  refer to property package for default balance type **MaterialBalanceType.none  exclude material balances, MaterialBalanceType.componentPhase  use phase component balances, MaterialBalanceType.componentTotal  use total component balances, MaterialBalanceType.elementTotal  use total element balances, MaterialBalanceType.total  use total material balance.}
 energy_balance_type
 Indicates what type of energy balance should be constructed, default  EnergyBalanceType.useDefault. Valid values: { EnergyBalanceType.useDefault  refer to property package for default balance type **EnergyBalanceType.none  exclude energy balances, EnergyBalanceType.enthalpyTotal  single enthalpy balance for material, EnergyBalanceType.enthalpyPhase  enthalpy balances for each phase, EnergyBalanceType.energyTotal  single energy balance for material, EnergyBalanceType.energyPhase  energy balances for each phase.}
 momentum_balance_type
 Indicates what type of momentum balance should be constructed, default  MomentumBalanceType.pressureTotal. Valid values: { MomentumBalanceType.none  exclude momentum balances, MomentumBalanceType.pressureTotal  single pressure balance for material, MomentumBalanceType.pressurePhase  pressure balances for each phase, MomentumBalanceType.momentumTotal  single momentum balance for material, MomentumBalanceType.momentumPhase  momentum balances for each phase.}
 has_pressure_change
 Indicates whether terms for pressure change should be constructed, default  False. Valid values: { True  include pressure change terms, False  exclude pressure change terms.}
 has_phase_equilibrium
 Argument to enable phase equilibrium on the shell side.  True  include phase equilibrium term  False  do not include phase equilibrium term
 property_package
 Property parameter object used to define property calculations (default = â€use_parent_valueâ€™)  â€use_parent_valueâ€™  get package from parent (default = None)  a ParameterBlock object
 property_package_args
 A dict of arguments to be passed to the PropertyBlockData and used when constructing these (default = â€use_parent_valueâ€™)  â€use_parent_valueâ€™  get package from parent (default = None)  a dict (see property package for documentation)
 transformation_method
 Discretization method to use for DAE transformation. See Pyomo documentation for supported transformations.
 transformation_scheme
 Discretization scheme to use when transformating domain. See Pyomo documentation for supported schemes.
 tube_side
 tube side config arguments
 dynamic
 Indicates whether this model will be dynamic or not, default = useDefault. Valid values: { useDefault  get flag from parent (default = False), True  set as a dynamic model, False  set as a steadystate model.}
 has_holdup
 Indicates whether holdup terms should be constructed or not. Must be True if dynamic = True, default  False. Valid values: { True  construct holdup terms, False  do not construct holdup terms}
 material_balance_type
 Indicates what type of mass balance should be constructed, default  MaterialBalanceType.useDefault. Valid values: { MaterialBalanceType.useDefault  refer to property package for default balance type **MaterialBalanceType.none  exclude material balances, MaterialBalanceType.componentPhase  use phase component balances, MaterialBalanceType.componentTotal  use total component balances, MaterialBalanceType.elementTotal  use total element balances, MaterialBalanceType.total  use total material balance.}
 energy_balance_type
 Indicates what type of energy balance should be constructed, default  EnergyBalanceType.useDefault. Valid values: { EnergyBalanceType.useDefault  refer to property package for default balance type **EnergyBalanceType.none  exclude energy balances, EnergyBalanceType.enthalpyTotal  single enthalpy balance for material, EnergyBalanceType.enthalpyPhase  enthalpy balances for each phase, EnergyBalanceType.energyTotal  single energy balance for material, EnergyBalanceType.energyPhase  energy balances for each phase.}
 momentum_balance_type
 Indicates what type of momentum balance should be constructed, default  MomentumBalanceType.pressureTotal. Valid values: { MomentumBalanceType.none  exclude momentum balances, MomentumBalanceType.pressureTotal  single pressure balance for material, MomentumBalanceType.pressurePhase  pressure balances for each phase, MomentumBalanceType.momentumTotal  single momentum balance for material, MomentumBalanceType.momentumPhase  momentum balances for each phase.}
 has_pressure_change
 Indicates whether terms for pressure change should be constructed, default  False. Valid values: { True  include pressure change terms, False  exclude pressure change terms.}
 has_phase_equilibrium
 Argument to enable phase equilibrium on the shell side.  True  include phase equilibrium term  False  do not include phase equilibrium term
 property_package
 Property parameter object used to define property calculations (default = â€use_parent_valueâ€™)  â€use_parent_valueâ€™  get package from parent (default = None)  a ParameterBlock object
 property_package_args
 A dict of arguments to be passed to the PropertyBlockData and used when constructing these (default = â€use_parent_valueâ€™)  â€use_parent_valueâ€™  get package from parent (default = None)  a dict (see property package for documentation)
 transformation_method
 Discretization method to use for DAE transformation. See Pyomo documentation for supported transformations.
 transformation_scheme
 Discretization scheme to use when transformating domain. See Pyomo documentation for supported schemes.
 finite_elements
 Number of finite elements to use when discretizing length domain (default=20)
 collocation_points
 Number of collocation points to use per finite element when discretizing length domain (default=3)
 flow_type
 Flow configuration of heat exchanger  HeatExchangerFlowPattern.cocurrent: shell and tube flows from 0 to 1 (default)  HeatExchangerFlowPattern.countercurrent: shell side flows from 0 to 1 tube side flows from 1 to 0
 has_wall_conduction
 Argument to enable type of wall heat conduction model.  WallConductionType.zero_dimensional  0D wall model (default),  WallConductionType.one_dimensional  1D wall model along the thickness of the tube,  WallConductionType.two_dimensional  2D wall model along the lenghth and thickness of the tube
 initialize (dict) â€“ ProcessBlockData config for individual elements. Keys are BlockData indexes and values are dictionaries described under the â€śdefaultâ€ť argument above.
 idx_map (function) â€“ Function to take the index of a BlockData element and return the index in the initialize dict from which to read arguments. This can be provided to overide the default behavior of matching the BlockData index exactly to the index in initialize.
Returns: (HeatExchanger1D) New instance
HeatExchanger1dDataClassÂ¶

class
idaes.unit_models.heat_exchanger_1D.
HeatExchanger1DData
(component)[source]Â¶ Standard Heat Exchanger 1D Unit Model Class.

initialize
(shell_state_args=None, tube_state_args=None, outlvl=1, solver='ipopt', optarg={'tol': 1e06})[source]Â¶ Initialisation routine for the unit (default solver ipopt).
Keyword Arguments:  state_args â€“ a dict of arguments to be passed to the property package(s) to provide an initial state for initialization (see documentation of the specific property package) (default = {}).
 outlvl â€“
sets output level of initialisation routine
 0 = no output (default)
 1 = return solver state for each step in routine
 2 = return solver state for each step in subroutines
 3 = include solver output infomation (tee=True)
 optarg â€“ solver options dictionary object (default={â€tolâ€™: 1e6})
 solver â€“ str indicating whcih solver to use during initialization (default = â€ipoptâ€™)
Returns: None

MixerÂ¶
The IDAES Mixer unit model represents operations where multiple streams of material are combined into a single flow. The Mixer class can be used to create either a standalone mixer unit, or as part of a unit model where multiple streams need to be mixed.
Degrees of FreedomÂ¶
Mixer units have zero degrees of freedom.
Model StructureÂ¶
The IDAES Mixer unit model does not use ControlVolumes, and instead writes a set of material, energy and momentum balances to combine the inlet streams into a single mixed stream. Mixer models have a userdefined number of inlet Ports (by default named inlet_1, inlet_2, etc.) and one outlet Port (named outlet).
Mixed State Block
If a mixed state block is provided in the construction arguments, the Mixer model will use this as the StateBlock for the mixed stream in the resulting balance equations. This allows a Mixer unit to be used as part of a larger unit operation by linking multiple inlet streams to a single existing StateBlock.
VariablesÂ¶
Mixer units have the following variables (\(i\) indicates index by inlet):
Variable Name  Symbol  Notes 

phase_equilibrium_generation  \(X_{eq, t, r}\)  Only if has_phase_equilibrium = True, Generation term for phase equilibrium 
minimum_pressure  \(P_{min, t, i}\)  Only if momentum_mixing_type = MomemntumMixingType.minimize 
ParametersÂ¶
Mixer units have the following parameters:
Variable Name  Symbol  Notes 

eps_pressure  \(\epsilon\)  Only if momentum_mixing_type = MomemntumMixingType.minimize, smooth minimum parameter 
ConstraintsÂ¶
The constraints written by the Mixer model depend upon the construction arguments chosen.
If material_mixing_type is extensive:
 If material_balance_type is componentPhase:
material_mixing_equations(t, p, j):
 If material_balance_type is componentTotal:
material_mixing_equations(t, j):
 If material_balance_type is total:
material_mixing_equations(t):
where \(n_{r, p, j}\) is the stoichiometric coefficient of component \(j\) in phase \(p\) in reaction \(r\).
If â€energy_mixing_type` is extensive:
enthalpy_mixing_equations(t):
If â€momentum_mixing_type` is minimize, a series of smooth minimum operations are performed:
minimum_pressure_constraint(t, i):
For the first inlet:
\[P_{min, t, i} = P_{t, i}\]Otherwise:
\[P_{min, t, i} = smin(P_{min, t, i1}, P_{t, i}, eps)\]
Here, \(P_{t, i}\) is the pressure in inlet \(i\) at time \(t\), \(P_{min, t, i}\) is the minimum pressure in all inlets up to inlet \(i\), and \(smin\) is the smooth minimum operator (see IDAES Utility Function documentation).
The minimum pressure in all inlets is then:
mixture_pressure(t):
If momentum_mixing_type is equality, the pressure in all inlets and the outlet are equated.
Note
This may result in an overspecified problem if the user is not careful.
pressure_equality_constraints(t, i):
Often the minimum inlet pressure constraint is useful for sequential modular type initialization, but the equal pressure constants are required for pressuredriven flow models. In these cases it may be convenient to use the minimum pressure constraint for some initialization steps, them deactivate it and use the equal pressure constraints. The momentum_mixing_type is minimum_and_equality this will create the constraints for both with the minimum pressure constraint being active.
The mixture_pressure(t) and pressure_equality_constraints(t, i) can be directly activated and deactivated, but only one set of constraints should be active at a time. The use_minimum_inlet_pressure_constraint()
and use_equal_pressure_constraint()
methods are also provided to switch between constant sets.
Mixer ClassÂ¶

class
idaes.unit_models.mixer.
Mixer
(*args, **kwargs)Â¶ Parameters:  rule (function) â€“ A rule function or None. Default rule calls build().
 concrete (bool) â€“ If True, make this a toplevel model. Default  False.
 ctype (str) â€“ Pyomo ctype of the block. Default  â€śBlockâ€ť
 default (dict) â€“
Default ProcessBlockData config
 Keys
 dynamic
 Indicates whether this model will be dynamic or not, default = False. Mixer blocks are always steadystate.
 has_holdup
 Mixer blocks do not contain holdup, thus this must be False.
 property_package
 Property parameter object used to define property calculations, default  useDefault. Valid values: { useDefault  use default package from parent model or flowsheet, PropertyParameterObject  a PropertyParameterBlock object.}
 property_package_args
 A ConfigBlock with arguments to be passed to a property block(s) and used when constructing these, default  None. Valid values: { see property package for documentation.}
 inlet_list
 A list containing names of inlets, default  None. Valid values: { None  use num_inlets argument, list  a list of names to use for inlets.}
 num_inlets
 Argument indicating number (int) of inlets to construct, not used if inlet_list arg is provided, default  None. Valid values: { None  use inlet_list arg instead, or default to 2 if neither argument provided, int  number of inlets to create (will be named with sequential integers from 1 to num_inlets).}
 material_balance_type
 Indicates what type of mass balance should be constructed, default  MaterialBalanceType.useDefault. Valid values: { MaterialBalanceType.useDefault  refer to property package for default balance type **MaterialBalanceType.none  exclude material balances, MaterialBalanceType.componentPhase  use phase component balances, MaterialBalanceType.componentTotal  use total component balances, MaterialBalanceType.elementTotal  use total element balances, MaterialBalanceType.total  use total material balance.}
 has_phase_equilibrium
 Argument indicating whether phase equilibrium should be calculated for the resulting mixed stream, default  False. Valid values: { True  calculate phase equilibrium in mixed stream, False  do not calculate equilibrium in mixed stream.}
 energy_mixing_type
 Argument indicating what method to use when mixing energy flows of incoming streams, default  MixingType.extensive. Valid values: { MixingType.none  do not include energy mixing equations, MixingType.extensive  mix total enthalpy flows of each phase.}
 momentum_mixing_type
 Argument indicating what method to use when mixing momentum/ pressure of incoming streams, default  MomentumMixingType.minimize. Valid values: { MomentumMixingType.none  do not include momentum mixing equations, MomentumMixingType.minimize  mixed stream has pressure equal to the minimimum pressure of the incoming streams (uses smoothMin operator), MomentumMixingType.equality  enforces equality of pressure in mixed and all incoming streams., MomentumMixingType.minimize_and_equality  add constraints for pressure equal to the minimum pressure of the inlets and constraints for equality of pressure in mixed and all incoming streams. When the model is initially built, the equality constraints are deactivated. This option is useful for switching between flow and pressure driven simulations.}
 mixed_state_block
 An existing state block to use as the outlet stream from the Mixer block, default  None. Valid values: { None  create a new StateBlock for the mixed stream, StateBlock  a StateBock to use as the destination for the mixed stream.}
 construct_ports
 Argument indicating whether model should construct Port objects linked to all inlet states and the mixed state, default  True. Valid values: { True  construct Ports for all states, False  do not construct Ports.
 initialize (dict) â€“ ProcessBlockData config for individual elements. Keys are BlockData indexes and values are dictionaries described under the â€śdefaultâ€ť argument above.
 idx_map (function) â€“ Function to take the index of a BlockData element and return the index in the initialize dict from which to read arguments. This can be provided to overide the default behavior of matching the BlockData index exactly to the index in initialize.
Returns: (Mixer) New instance
MixerData ClassÂ¶

class
idaes.unit_models.mixer.
MixerData
(component)[source]Â¶ This is a general purpose model for a Mixer block with the IDAES modeling framework. This block can be used either as a standalone Mixer unit operation, or as a submodel within another unit operation.
This model creates a number of StateBlocks to represent the incoming streams, then writes a set of phasecomponent material balances, an overall enthalpy balance and a momentum balance (2 options) linked to a mixedstate StateBlock. The mixedstate StateBlock can either be specified by the user (allowing use as a submodel), or created by the Mixer.
When being used as a submodel, Mixer should only be used when a set of new StateBlocks are required for the streams to be mixed. It should not be used to mix streams from mutiple ControlVolumes in a single unit model  in these cases the unit model developer should write their own mixing equations.

add_energy_mixing_equations
(inlet_blocks, mixed_block)[source]Â¶ Add energy mixing equations (total enthalpy balance).

add_inlet_state_blocks
(inlet_list)[source]Â¶ Construct StateBlocks for all inlet streams.
Parameters: of strings to use as StateBlock names (list) â€“ Returns: list of StateBlocks

add_material_mixing_equations
(inlet_blocks, mixed_block, mb_type)[source]Â¶ Add material mixing equations.

add_mixed_state_block
()[source]Â¶ Constructs StateBlock to represent mixed stream.
Returns: New StateBlock object

add_port_objects
(inlet_list, inlet_blocks, mixed_block)[source]Â¶ Adds Port objects if required.
Parameters:  list of inlet StateBlock objects (a) â€“
 mixed state StateBlock object (a) â€“
Returns: None

add_pressure_equality_equations
(inlet_blocks, mixed_block)[source]Â¶ Add pressure equality equations. Note that this writes a number of constraints equal to the number of inlets, enforcing equality between all inlets and the mixed stream.

add_pressure_minimization_equations
(inlet_blocks, mixed_block)[source]Â¶ Add pressure minimization equations. This is done by sequential comparisons of each inlet to the minimum pressure so far, using the IDAES smooth minimum fuction.

build
()[source]Â¶ General build method for MixerData. This method calls a number of submethods which automate the construction of expected attributes of unit models.
Inheriting models should call super().build.
Parameters: None â€“ Returns: None

create_inlet_list
()[source]Â¶ Create list of inlet stream names based on config arguments.
Returns: list of strings

get_mixed_state_block
()[source]Â¶ Validates StateBlock provided in user arguments for mixed stream.
Returns: The userprovided StateBlock or an Exception

initialize
(outlvl=0, optarg={}, solver='ipopt', hold_state=False)[source]Â¶ Initialisation routine for mixer (default solver ipopt)
Keyword Arguments:  outlvl â€“ sets output level of initialisation routine. Valid values: 0  no output (default), 1  return solver state for each step in routine, 2  include solver output infomation (tee=True)
 optarg â€“ solver options dictionary object (default={})
 solver â€“ str indicating whcih solver to use during initialization (default = â€ipoptâ€™)
 hold_state â€“ flag indicating whether the initialization routine should unfix any state variables fixed during initialization, default  False. Valid values: True  states variables are not unfixed, and a dict of returned containing flags for which states were fixed during initialization, False  state variables are unfixed after initialization by calling the release_state method.
Returns: If hold_states is True, returns a dict containing flags for which states were fixed during initialization.

model_check
()[source]Â¶ This method executes the model_check methods on the associated state blocks (if they exist). This method is generally called by a unit model as part of the unitâ€™s model_check method.
Parameters: None â€“ Returns: None

release_state
(flags, outlvl=0)[source]Â¶ Method to release state variables fixed during initialisation.
Keyword Arguments:  flags â€“ dict containing information of which state variables were fixed during initialization, and should now be unfixed. This dict is returned by initialize if hold_state = True.
 outlvl â€“ sets output level of logging
Returns: None

Plug Flow ReactorÂ¶
The IDAES Plug Flow Reactor (PFR) model represents a unit operation where a material stream passes through a linear reactor vessel whilst undergoing some chemical reaction(s). This model requires modeling the system in one spatial dimension.
Degrees of FreedomÂ¶
PFRs generally have at least 2 degrees of freedom.
Typical fixed variables are:
 2 of reactor length, area and volume.
Model StructureÂ¶
The core PFR unit model consists of a single ControlVolume1DBlock (named control_volume) with one Inlet Port (named inlet) and one Outlet Port (named outlet).
VariablesÂ¶
PFR units add the following additional Variables:
Variable  Name  Notes 

\(L\)  length  Reference to control_volume.length 
\(A\)  area  Reference to control_volume.area 
\(V\)  volume  Reference to control_volume.volume 
\(Q_{t,x}\)  heat  Only if has_heat_transfer = True, reference to holdup.heat 
\(\Delta P_{t,x}\)  deltaP  Only if has_pressure_change = True, reference to holdup.deltaP 
ConstraintsÂ¶
PFR units write the following additional Constraints at all points in the spatial domain:
where \(X_{t,x,r}\) is the extent of reaction of reaction \(r\) at point \(x\) and time \(t\), \(A\) is the crosssectional area of the reactor and \(r_{t,r}\) is the volumetric rate of reaction of reaction \(r\) at point \(x\) and time \(t\) (from the outlet StateBlock).
PFR ClassÂ¶

class
idaes.unit_models.plug_flow_reactor.
PFR
(*args, **kwargs)Â¶ Parameters:  rule (function) â€“ A rule function or None. Default rule calls build().
 concrete (bool) â€“ If True, make this a toplevel model. Default  False.
 ctype (str) â€“ Pyomo ctype of the block. Default  â€śBlockâ€ť
 default (dict) â€“
Default ProcessBlockData config
 Keys
 dynamic
 Indicates whether this model will be dynamic or not, default = useDefault. Valid values: { useDefault  get flag from parent (default = False), True  set as a dynamic model, False  set as a steadystate model.}
 has_holdup
 Indicates whether holdup terms should be constructed or not. Must be True if dynamic = True, default  False. Valid values: { True  construct holdup terms, False  do not construct holdup terms}
 material_balance_type
 Indicates what type of mass balance should be constructed, default  MaterialBalanceType.useDefault. Valid values: { MaterialBalanceType.useDefault  refer to property package for default balance type **MaterialBalanceType.none  exclude material balances, MaterialBalanceType.componentPhase  use phase component balances, MaterialBalanceType.componentTotal  use total component balances, MaterialBalanceType.elementTotal  use total element balances, MaterialBalanceType.total  use total material balance.}
 energy_balance_type
 Indicates what type of energy balance should be constructed, default  EnergyBalanceType.useDefault. Valid values: { EnergyBalanceType.useDefault  refer to property package for default balance type **EnergyBalanceType.none  exclude energy balances, EnergyBalanceType.enthalpyTotal  single enthalpy balance for material, EnergyBalanceType.enthalpyPhase  enthalpy balances for each phase, EnergyBalanceType.energyTotal  single energy balance for material, EnergyBalanceType.energyPhase  energy balances for each phase.}
 momentum_balance_type
 Indicates what type of momentum balance should be constructed, default  MomentumBalanceType.pressureTotal. Valid values: { MomentumBalanceType.none  exclude momentum balances, MomentumBalanceType.pressureTotal  single pressure balance for material, MomentumBalanceType.pressurePhase  pressure balances for each phase, MomentumBalanceType.momentumTotal  single momentum balance for material, MomentumBalanceType.momentumPhase  momentum balances for each phase.}
 has_equilibrium_reactions
 Indicates whether terms for equilibrium controlled reactions should be constructed, default  True. Valid values: { True  include equilibrium reaction terms, False  exclude equilibrium reaction terms.}
 has_phase_equilibrium
 Indicates whether terms for phase equilibrium should be constructed, default = False. Valid values: { True  include phase equilibrium terms False  exclude phase equilibrium terms.}
 has_heat_of_reaction
 Indicates whether terms for heat of reaction terms should be constructed, default  False. Valid values: { True  include heat of reaction terms, False  exclude heat of reaction terms.}
 has_heat_transfer
 Indicates whether terms for heat transfer should be constructed, default  False. Valid values: { True  include heat transfer terms, False  exclude heat transfer terms.}
 has_pressure_change
 Indicates whether terms for pressure change should be constructed, default  False. Valid values: { True  include pressure change terms, False  exclude pressure change terms.}
 property_package
 Property parameter object used to define property calculations, default  useDefault. Valid values: { useDefault  use default package from parent model or flowsheet, PropertyParameterObject  a PropertyParameterBlock object.}
 property_package_args
 A ConfigBlock with arguments to be passed to a property block(s) and used when constructing these, default  None. Valid values: { see property package for documentation.}
 reaction_package
 Reaction parameter object used to define reaction calculations, default  None. Valid values: { None  no reaction package, ReactionParameterBlock  a ReactionParameterBlock object.}
 reaction_package_args
 A ConfigBlock with arguments to be passed to a reaction block(s) and used when constructing these, default  None. Valid values: { see reaction package for documentation.}
 length_domain_set
 A list of values to be used when constructing the length domain of the reactor. Point must lie between 0.0 and 1.0, default  [0.0, 1.0]. Valid values: { a list of floats}
 transformation_method
 Method to use to transform domain. Must be a method recognised by the Pyomo TransformationFactory, default  â€śdae.finite_differenceâ€ť.
 transformation_scheme
 Scheme to use when transformating domain. See Pyomo documentation for supported schemes, default  â€śBACKWARDâ€ť.
 finite_elements
 Number of finite elements to use when transforming length domain, default  20.
 collocation_points
 Number of collocation points to use when transforming length domain, default  3.
 initialize (dict) â€“ ProcessBlockData config for individual elements. Keys are BlockData indexes and values are dictionaries described under the â€śdefaultâ€ť argument above.
 idx_map (function) â€“ Function to take the index of a BlockData element and return the index in the initialize dict from which to read arguments. This can be provided to overide the default behavior of matching the BlockData index exactly to the index in initialize.
Returns: (PFR) New instance
Pressure ChangerÂ¶
The IDAES Pressure Changer model represents a unit operation with a single stream of material which undergoes a change in pressure due to the application of a work. The Pressure Changer model contains support for a number of different thermodynamic assumptions regarding the working fluid.
Degrees of FreedomÂ¶
Pressure Changer units generally have one or more degrees of freedom, depending on the thermodynamic assumption used.
Typical fixed variables are:
 outlet pressure, \(P_{ratio}\) or \(\Delta P\),
 unit efficiency (isentropic or pump assumption).
Model StructureÂ¶
The core Pressure Changer unit model consists of a single ControlVolume0D
(named control_volume
) with one Inlet Port (named inlet
) and one Outlet Port (named outlet
). Additionally, if an isentropic pressure changer is used, the unit model contains an additional StateBlock
named properties_isentropic
at the unit model level.
VariablesÂ¶
Pressure Changers contain the following Variables (not including those contained within the control volume Block):
Variable  Name  Notes 

\(P_{ratio}\)  ratioP  
\(V_t\)  volume  Only if has_rate_reactions = True, reference to control_volume.rate_reaction_extent 
\(W_{mechanical,t}\)  work_mechanical  Reference to control_volume.work 
\(W_{fluid,t}\)  work_fluid  Pump assumption only 
\(\eta_{pump,t}\)  efficiency_pump  Pump assumption only 
\(W_{isentropic,t}\)  work_isentropic  Isentropic assumption only 
\(\eta_{isentropic,t}\)  efficiency_isentropic  Isentropic assumption only 
Isentropic Pressure Changers also have an additional Property Block named properties_isentropic (attached to the Unit Model).
ConstraintsÂ¶
In addition to the Constraints written by the Control Volume block, Pressure Changer writes additional Constraints which depend on the thermodynamic assumption chosen. All Pressure Changers add the following Constraint to calculate the pressure ratio:
Isothermal AssumptionÂ¶
The isothermal assumption writes one additional Constraint:
Adiabatic AssumptionÂ¶
The isothermal assumption writes one additional Constraint:
Isentropic AssumptionÂ¶
The isentropic assumption creates an additional set of Property Blocks (indexed by time) for the isentropic fluid calculations (named properties_isentropic). This requires a set of balance equations relating the inlet state to the isentropic conditions, which are shown below:
where \(F_{t,p,j}\) is the flow of component \(j\) in phase \(p\) at time \(t\) and \(s\) is the specific entropy of the fluid at time \(t\).
Next, the isentropic work is calculated as follows:
where \(H_{t,p}\) is the total energy flow of phase \(p\) at time \(t\). Finally, a constraint which relates the fluid work to the actual mechanical work via an efficiency term \(\eta\).
If compressor is True, \(W_{isentropic,t} = W_{mechanical,t} \times \eta_t\)
If compressor is False, \(W_{isentropic,t} \times \eta_t = W_{mechanical,t}\)
Pump (Incompressible Fluid) AssumptionÂ¶
The incompressible fluid assumption writes two additional constraints. Firstly, a Constraint is written which relates fluid work to the pressure change of the fluid.
where \(F_{vol,t}\) is the total volumetric flowrate of material at time \(t\) (from the outlet Property Block). Secondly, a constraint which relates the fluid work to the actual mechanical work via an efficiency term \(\eta\).
If compressor is True, \(W_{fluid,t} = W_{mechanical,t} \times \eta_t\)
If compressor is False, \(W_{fluid,t} \times \eta_t = W_{mechanical,t}\)
PressureChanger ClassÂ¶

class
idaes.unit_models.pressure_changer.
PressureChanger
(*args, **kwargs)Â¶ Parameters:  rule (function) â€“ A rule function or None. Default rule calls build().
 concrete (bool) â€“ If True, make this a toplevel model. Default  False.
 ctype (str) â€“ Pyomo ctype of the block. Default  â€śBlockâ€ť
 default (dict) â€“
Default ProcessBlockData config
 Keys
 dynamic
 Indicates whether this model will be dynamic or not, default = useDefault. Valid values: { useDefault  get flag from parent (default = False), True  set as a dynamic model, False  set as a steadystate model.}
 has_holdup
 Indicates whether holdup terms should be constructed or not. Must be True if dynamic = True, default  False. Valid values: { True  construct holdup terms, False  do not construct holdup terms}
 material_balance_type
 Indicates what type of mass balance should be constructed, default  MaterialBalanceType.useDefault. Valid values: { MaterialBalanceType.useDefault  refer to property package for default balance type **MaterialBalanceType.none  exclude material balances, MaterialBalanceType.componentPhase  use phase component balances, MaterialBalanceType.componentTotal  use total component balances, MaterialBalanceType.elementTotal  use total element balances, MaterialBalanceType.total  use total material balance.}
 energy_balance_type
 Indicates what type of energy balance should be constructed, default  EnergyBalanceType.useDefault. Valid values: { EnergyBalanceType.useDefault  refer to property package for default balance type **EnergyBalanceType.none  exclude energy balances, EnergyBalanceType.enthalpyTotal  single enthalpy balance for material, EnergyBalanceType.enthalpyPhase  enthalpy balances for each phase, EnergyBalanceType.energyTotal  single energy balance for material, EnergyBalanceType.energyPhase  energy balances for each phase.}
 momentum_balance_type
 Indicates what type of momentum balance should be constructed, default  MomentumBalanceType.pressureTotal. Valid values: { MomentumBalanceType.none  exclude momentum balances, MomentumBalanceType.pressureTotal  single pressure balance for material, MomentumBalanceType.pressurePhase  pressure balances for each phase, MomentumBalanceType.momentumTotal  single momentum balance for material, MomentumBalanceType.momentumPhase  momentum balances for each phase.}
 has_phase_equilibrium
 Indicates whether terms for phase equilibrium should be constructed, default = False. Valid values: { True  include phase equilibrium terms False  exclude phase equilibrium terms.}
 compressor
 Indicates whether this unit should be considered a compressor (True (default), pressure increase) or an expander (False, pressure decrease).
 thermodynamic_assumption
 Flag to set the thermodynamic assumption to use for the unit.  ThermodynamicAssumption.isothermal (default)  ThermodynamicAssumption.isentropic  ThermodynamicAssumption.pump  ThermodynamicAssumption.adiabatic
 property_package
 Property parameter object used to define property calculations, default  useDefault. Valid values: { useDefault  use default package from parent model or flowsheet, PropertyParameterObject  a PropertyParameterBlock object.}
 property_package_args
 A ConfigBlock with arguments to be passed to a property block(s) and used when constructing these, default  None. Valid values: { see property package for documentation.}
 initialize (dict) â€“ ProcessBlockData config for individual elements. Keys are BlockData indexes and values are dictionaries described under the â€śdefaultâ€ť argument above.
 idx_map (function) â€“ Function to take the index of a BlockData element and return the index in the initialize dict from which to read arguments. This can be provided to overide the default behavior of matching the BlockData index exactly to the index in initialize.
Returns: (PressureChanger) New instance
PressureChangerData ClassÂ¶

class
idaes.unit_models.pressure_changer.
PressureChangerData
(component)[source]Â¶ Standard Compressor/Expander Unit Model Class

add_adiabatic
()[source]Â¶ Add constraints for adiabatic assumption.
Parameters: None â€“ Returns: None

add_isentropic
()[source]Â¶ Add constraints for isentropic assumption.
Parameters: None â€“ Returns: None

add_isothermal
()[source]Â¶ Add constraints for isothermal assumption.
Parameters: None â€“ Returns: None

add_pump
()[source]Â¶ Add constraints for the incompressible fluid assumption
Parameters: None â€“ Returns: None

init_isentropic
(state_args, outlvl, solver, optarg)[source]Â¶ Initialisation routine for unit (default solver ipopt)
Keyword Arguments:  state_args â€“ a dict of arguments to be passed to the property package(s) to provide an initial state for initialization (see documentation of the specific property package) (default = {}).
 outlvl â€“
sets output level of initialisation routine
 0 = no output (default)
 1 = return solver state for each step in routine
 2 = return solver state for each step in subroutines
 3 = include solver output infomation (tee=True)
 optarg â€“ solver options dictionary object (default={â€tolâ€™: 1e6})
 solver â€“ str indicating whcih solver to use during initialization (default = â€ipoptâ€™)
Returns: None

initialize
(state_args=None, routine=None, outlvl=0, solver='ipopt', optarg={'tol': 1e06})[source]Â¶ General wrapper for pressure changer initialisation routines
Keyword Arguments:  routine â€“ str stating which initialization routine to execute * None  use routine matching thermodynamic_assumption * â€isentropicâ€™  use isentropic initialization routine * â€isothermalâ€™  use isothermal initialization routine
 state_args â€“ a dict of arguments to be passed to the property package(s) to provide an initial state for initialization (see documentation of the specific property package) (default = {}).
 outlvl â€“
sets output level of initialisation routine
 0 = no output (default)
 1 = return solver state for each step in routine
 2 = return solver state for each step in subroutines
 3 = include solver output infomation (tee=True)
 optarg â€“ solver options dictionary object (default={â€tolâ€™: 1e6})
 solver â€“ str indicating whcih solver to use during initialization (default = â€ipoptâ€™)
Returns: None

Product BlockÂ¶
Product Blocks are used to represent sinks of material in Flowsheets. These can be used as a conventient way to mark the final destination of a material stream and to view the state of that material.
Degrees of FreedomÂ¶
Product blocks generally have zero degrees of freedom.
Model StructureÂ¶
Product Blocks consists of a single StateBlock (named properties), each with one Inlet Port (named inlet). Product Blocks also contain References to the state variables defined within the StateBlock
Additional ConstraintsÂ¶
Product Blocks write no additional constraints to the model.
VariablesÂ¶
Product blocks add no additional Variables.
Product ClassÂ¶

class
idaes.unit_models.product.
Product
(*args, **kwargs)Â¶ Parameters:  rule (function) â€“ A rule function or None. Default rule calls build().
 concrete (bool) â€“ If True, make this a toplevel model. Default  False.
 ctype (str) â€“ Pyomo ctype of the block. Default  â€śBlockâ€ť
 default (dict) â€“
Default ProcessBlockData config
 Keys
 dynamic
 Indicates whether this model will be dynamic or not, default = False. Product blocks are always steady state.
 has_holdup
 Product blocks do not contain holdup, thus this must be False.
 property_package
 Property parameter object used to define property calculations, default  useDefault. Valid values: { useDefault  use default package from parent model or flowsheet, PhysicalParameterObject  a PhysicalParameterBlock object.}
 property_package_args
 A ConfigBlock with arguments to be passed to a property block(s) and used when constructing these, default  None. Valid values: { see property package for documentation.}
 initialize (dict) â€“ ProcessBlockData config for individual elements. Keys are BlockData indexes and values are dictionaries described under the â€śdefaultâ€ť argument above.
 idx_map (function) â€“ Function to take the index of a BlockData element and return the index in the initialize dict from which to read arguments. This can be provided to overide the default behavior of matching the BlockData index exactly to the index in initialize.
Returns: (Product) New instance
ProductData ClassÂ¶

class
idaes.unit_models.product.
ProductData
(component)[source]Â¶ Standard Product Block Class

initialize
(state_args={}, outlvl=0, solver='ipopt', optarg={'tol': 1e06})[source]Â¶ This method calls the initialization method of the state block.
Keyword Arguments:  state_args â€“ a dict of arguments to be passed to the property package(s) to provide an initial state for initialization (see documentation of the specific property package) (default = {}).
 outlvl â€“
sets output level of initialisation routine
 0 = no output (default)
 1 = return solver state for each step in routine
 2 = return solver state for each step in subroutines
 3 = include solver output infomation (tee=True)
 optarg â€“ solver options dictionary object (default={â€tolâ€™: 1e6})
 solver â€“ str indicating which solver to use during initialization (default = â€ipoptâ€™)
Returns: None

SeparatorÂ¶
The IDAES Separator unit model represents operations where a single stream is split into multiple flows. The Separator model supports separation using split fractions, or by ideal separation of flows. The Separator class can be used to create either a standalone separator unit, or as part of a unit model where a flow needs to be separated.
Degrees of FreedomÂ¶
Separator units have a number of degrees of freedom based on the separation type chosen.
 If split_basis = â€phaseFlowâ€™, degrees of freedom are generally \((no. outlets1) \times no. phases\)
 If split_basis = â€componentFlowâ€™, degrees of freedom are generally \((no. outlets1) \times no. components\)
 If split_basis = â€phaseComponentFlowâ€™, degrees of freedom are generally \((no. outlets1) \times no. phases \times no. components\)
 If split_basis = â€totalFlowâ€™, degrees of freedom are generally \((no. outlets1) \times no. phases \times no. components\)
Typical fixed variables are:
 split fractions.
Model StructureÂ¶
The IDAES Separator unit model does not use ControlVolumes, and instead writes a set of material, energy and momentum balances to split the inlet stream into a number of outlet streams. Separator models have a single inlet Port (named inlet) and a userdefined number of outlet Ports (by default named outlet_1, outlet_2, etc.).
Mixed State Block
If a mixed state block is provided in the construction arguments, the Mixer model will use this as the StateBlock for the mixed stream in the resulting balance equations. This allows a Mixer unit to be used as part of a larger unit operation by linking to an existing StateBlock.
Ideal SeparationÂ¶
The IDAES Separator model supports ideal separations, where all of a given subset of the mixed stream is sent to a single outlet (i.e. split fractions are equal to zero or one). In these cases, no Constraints are necessary for performing the separation, as the mixed stream states can be directly partitioned to the outlets.
Ideal separations will not work for all choices of state variables, and thus will not work for all property packages. To use ideal separations, the user must provide a map of what part of the mixed flow should be partitioned to each outlet. The ideal_split_map should be a dictlike object with keys as tuples matching the split_basis argument and values indicating which outlet this subset should be partitioned to.
VariablesÂ¶
Separator units have the following variables (\(o\) indicates index by outlet):
Variable Name  Symbol  Notes 

split_fraction  \(\phi_{t, o, *}\)  Indexing sets depend upon split_basis 
ConstraintsÂ¶
Separator units have the following Constraints, unless ideal_separation is True.
 If material_balance_type is componentPhase:
material_splitting_eqn(t, o, p, j):
 If material_balance_type is componentTotal:
material_splitting_eqn(t, o, j):
 If material_balance_type is total:
material_splitting_eqn(t, o):
If energy_split_basis is equal_temperature:
temperature_equality_eqn(t, o):
If energy_split_basis is equal_molar_enthalpy:
molar_enthalpy_equality_eqn(t, o):
If energy_split_basis is enthalpy_split:
molar_enthalpy_splitting_eqn(t, o):
pressure_equality_eqn(t, o):
Separator ClassÂ¶

class
idaes.unit_models.separator.
Separator
(*args, **kwargs)Â¶ Parameters:  rule (function) â€“ A rule function or None. Default rule calls build().
 concrete (bool) â€“ If True, make this a toplevel model. Default  False.
 ctype (str) â€“ Pyomo ctype of the block. Default  â€śBlockâ€ť
 default (dict) â€“
Default ProcessBlockData config
 Keys
 dynamic
 Indicates whether this model will be dynamic or not, default = False. Product blocks are always steady state.
 has_holdup
 Product blocks do not contain holdup, thus this must be False.
 property_package
 Property parameter object used to define property calculations, default  useDefault. Valid values: { useDefault  use default package from parent model or flowsheet, PropertyParameterObject  a PropertyParameterBlock object.}
 property_package_args
 A ConfigBlock with arguments to be passed to a property block(s) and used when constructing these, default  None. Valid values: { see property package for documentation.}
 outlet_list
 A list containing names of outlets, default  None. Valid values: { None  use num_outlets argument, list  a list of names to use for outlets.}
 num_outlets
 Argument indicating number (int) of outlets to construct, not used if outlet_list arg is provided, default  None. Valid values: { None  use outlet_list arg instead, or default to 2 if neither argument provided, int  number of outlets to create (will be named with sequential integers from 1 to num_outlets).}
 split_basis
 Argument indicating basis to use for splitting mixed stream, default  SplittingType.totalFlow. Valid values: { SplittingType.totalFlow  split based on total flow (split fraction indexed only by time and outlet), SplittingType.phaseFlow  split based on phase flows (split fraction indexed by time, outlet and phase), SplittingType.componentFlow  split based on component flows (split fraction indexed by time, outlet and components), SplittingType.phaseComponentFlow  split based on phasecomponent flows ( split fraction indexed by both time, outlet, phase and components).}
 material_balance_type
 Indicates what type of mass balance should be constructed, default  MaterialBalanceType.useDefault. Valid values: { MaterialBalanceType.useDefault  refer to property package for default balance type **MaterialBalanceType.none  exclude material balances, MaterialBalanceType.componentPhase  use phase component balances, MaterialBalanceType.componentTotal  use total component balances, MaterialBalanceType.elementTotal  use total element balances, MaterialBalanceType.total  use total material balance.}
 has_phase_equilibrium
 Argument indicating whether phase equilibrium should be calculated for the resulting mixed stream, default  False. Valid values: { True  calculate phase equilibrium in mixed stream, False  do not calculate equilibrium in mixed stream.}
 energy_split_basis
 Argument indicating basis to use for splitting energy this is not used for when ideal_separation == True. default  EnergySplittingType.equal_temperature. Valid values: { EnergySplittingType.equal_temperature  outlet temperatures equal inlet EnergySplittingType.equal_molar_enthalpy  oulet molar enthalpies equal inlet, EnergySplittingType.enthalpy_split  apply split fractions to enthalpy flows. Does not work with component or phasecomponent splitting.}
 ideal_separation
 Argument indicating whether ideal splitting should be used. Ideal splitting assumes perfect spearation of material, and attempts to avoid duplication of StateBlocks by directly partitioning outlet flows to ports, default  False. Valid values: { True  use ideal splitting methods. Cannot be combined with has_phase_equilibrium = True, False  use explicit splitting equations with split fractions.}
 ideal_split_map
 Dictionary containing information on how extensive variables should be partitioned when using ideal splitting (ideal_separation = True). default  None. Valid values: { dict with keys of indexing set members and values indicating which outlet this combination of keys should be partitioned to. E.g. {(â€śVapâ€ť, â€śH2â€ť): â€śoutlet_1â€ť}}
 mixed_state_block
 An existing state block to use as the source stream from the Separator block, default  None. Valid values: { None  create a new StateBlock for the mixed stream, StateBlock  a StateBock to use as the source for the mixed stream.}
 construct_ports
 Argument indicating whether model should construct Port objects linked the mixed state and all outlet states, default  True. Valid values: { True  construct Ports for all states, False  do not construct Ports.
 initialize (dict) â€“ ProcessBlockData config for individual elements. Keys are BlockData indexes and values are dictionaries described under the â€śdefaultâ€ť argument above.
 idx_map (function) â€“ Function to take the index of a BlockData element and return the index in the initialize dict from which to read arguments. This can be provided to overide the default behavior of matching the BlockData index exactly to the index in initialize.
Returns: (Separator) New instance
SeparatorData ClassÂ¶

class
idaes.unit_models.separator.
SeparatorData
(component)[source]Â¶ This is a general purpose model for a Separator block with the IDAES modeling framework. This block can be used either as a standalone Separator unit operation, or as a submodel within another unit operation.
This model creates a number of StateBlocks to represent the outgoing streams, then writes a set of phasecomponent material balances, an overall enthalpy balance (2 options), and a momentum balance (2 options) linked to a mixedstate StateBlock. The mixedstate StateBlock can either be specified by the user (allowing use as a submodel), or created by the Separator.
When being used as a submodel, Separator should only be used when a set of new StateBlocks are required for the streams to be separated. It should not be used to separate streams to go to mutiple ControlVolumes in a single unit model  in these cases the unit model developer should write their own splitting equations.

add_energy_splitting_constraints
(mixed_block)[source]Â¶ Creates constraints for splitting the energy flows  done by equating temperatures in outlets.

add_inlet_port_objects
(mixed_block)[source]Â¶ Adds inlet Port object if required.
Parameters: mixed state StateBlock object (a) â€“ Returns: None

add_material_splitting_constraints
(mixed_block)[source]Â¶ Creates constraints for splitting the material flows

add_mixed_state_block
()[source]Â¶ Constructs StateBlock to represent mixed stream.
Returns: New StateBlock object

add_momentum_splitting_constraints
(mixed_block)[source]Â¶ Creates constraints for splitting the momentum flows  done by equating pressures in outlets.

add_outlet_port_objects
(outlet_list, outlet_blocks)[source]Â¶ Adds outlet Port objects if required.
Parameters: list of outlet StateBlock objects (a) â€“ Returns: None

add_outlet_state_blocks
(outlet_list)[source]Â¶ Construct StateBlocks for all outlet streams.
Parameters: of strings to use as StateBlock names (list) â€“ Returns: list of StateBlocks

add_split_fractions
(outlet_list)[source]Â¶ Creates outlet Port objects and tries to partiton mixed stream flows between these
Parameters:  representing the mixed flow to be split (StateBlock) â€“
 list of names for outlets (a) â€“
Returns: None

build
()[source]Â¶ General build method for SeparatorData. This method calls a number of submethods which automate the construction of expected attributes of unit models.
Inheriting models should call super().build.
Parameters: None â€“ Returns: None

create_outlet_list
()[source]Â¶ Create list of outlet stream names based on config arguments.
Returns: list of strings

get_mixed_state_block
()[source]Â¶ Validates StateBlock provided in user arguments for mixed stream.
Returns: The userprovided StateBlock or an Exception

initialize
(outlvl=0, optarg={}, solver='ipopt', hold_state=False)[source]Â¶ Initialisation routine for separator (default solver ipopt)
Keyword Arguments:  outlvl â€“ sets output level of initialisation routine. Valid values: 0  no output (default), 1  return solver state for each step in routine, 2  include solver output infomation (tee=True)
 optarg â€“ solver options dictionary object (default=None)
 solver â€“ str indicating whcih solver to use during initialization (default = â€ipoptâ€™)
 hold_state â€“ flag indicating whether the initialization routine should unfix any state variables fixed during initialization, default  False. Valid values: True  states variables are not unfixed, and a dict of returned containing flags for which states were fixed during initialization, False  state variables are unfixed after initialization by calling the release_state method.
Returns: If hold_states is True, returns a dict containing flags for which states were fixed during initialization.

model_check
()[source]Â¶ This method executes the model_check methods on the associated state blocks (if they exist). This method is generally called by a unit model as part of the unitâ€™s model_check method.
Parameters: None â€“ Returns: None

partition_outlet_flows
(mb, outlet_list)[source]Â¶ Creates outlet Port objects and tries to partiton mixed stream flows between these
Parameters:  representing the mixed flow to be split (StateBlock) â€“
 list of names for outlets (a) â€“
Returns: None

release_state
(flags, outlvl=0)[source]Â¶ Method to release state variables fixed during initialisation.
Keyword Arguments:  flags â€“ dict containing information of which state variables were fixed during initialization, and should now be unfixed. This dict is returned by initialize if hold_state = True.
 outlvl â€“ sets output level of logging
Returns: None

StateJunction BlockÂ¶
The IDAES StateJunction block represents a passthrough unit or simple pipe with no holdup. The primary use for this unit is in conceptual design applications for linking Arcs to/from different process alternatives.
Degrees of FreedomÂ¶
StateJunctions have no degrees of freedom.
Model StructureÂ¶
A StateJunction consists of a single StateBlock with two Ports (inlet and outlet), where the state variables in the state block are simultaneously connected to both Ports.
Additional ConstraintsÂ¶
StateJunctions write no additional constraints beyond those in the StateBlock.
VariablesÂ¶
StateJunctions have no additional variables.
StateJunction ClassÂ¶

class
idaes.unit_models.statejunction.
StateJunction
(*args, **kwargs)Â¶ Parameters:  rule (function) â€“ A rule function or None. Default rule calls build().
 concrete (bool) â€“ If True, make this a toplevel model. Default  False.
 ctype (str) â€“ Pyomo ctype of the block. Default  â€śBlockâ€ť
 default (dict) â€“
Default ProcessBlockData config
 Keys
 dynamic
 Indicates whether this unit will be dynamic or not, default = False.
 has_holdup
 Indicates whether holdup terms should be constructed or not. default  False. StateJunctions do not have defined volume, thus this must be False.
 property_package
 Property parameter object used to define property state block, default  useDefault. Valid values: { useDefault  use default package from parent model or flowsheet, PhysicalParameterObject  a PhysicalParameterBlock object.}
 property_package_args
 A ConfigBlock with arguments to be passed to a property block(s) and used when constructing these, default  None. Valid values: { see property package for documentation.}
 initialize (dict) â€“ ProcessBlockData config for individual elements. Keys are BlockData indexes and values are dictionaries described under the â€śdefaultâ€ť argument above.
 idx_map (function) â€“ Function to take the index of a BlockData element and return the index in the initialize dict from which to read arguments. This can be provided to overide the default behavior of matching the BlockData index exactly to the index in initialize.
Returns: (StateJunction) New instance
StateJunctionData ClassÂ¶

class
idaes.unit_models.statejunction.
StateJunctionData
(component)[source]Â¶ Standard StateJunction Unit Model Class

initialize
(state_args={}, outlvl=0, solver='ipopt', optarg={'tol': 1e06})[source]Â¶ This method initializes the StateJunction block by calling the initialize method on the property block.
Keyword Arguments:  state_args â€“ a dict of arguments to be passed to the property package(s) to provide an initial state for initialization (see documentation of the specific property package) (default = {}).
 outlvl â€“
sets output level of initialisation routine
 0 = no output (default)
 1 = return solver state for each step in routine
 2 = return solver state for each step in subroutines
 3 = include solver output infomation (tee=True)
 optarg â€“ solver options dictionary object (default={â€tolâ€™: 1e6})
 solver â€“ str indicating which solver to use during initialization (default = â€ipoptâ€™)
Returns: None

Stoichiometric (Yield) ReactorÂ¶
The IDAES Stoichiometric reactor model represents a unit operation where a single material stream undergoes some chemical reaction(s) subject to a set of extent or yield specifications.
Degrees of FreedomÂ¶
Stoichiometric reactors generally have degrees of freedom equal to the number of reactions + 1.
Typical fixed variables are:
 reaction extents or yields (1 per reaction),
 reactor heat duty (has_heat_transfer = True only).
Model StructureÂ¶
The core Stoichiometric reactor unit model consists of a single ControlVolume0DBlock (named control_volume) with one Inlet Port (named inlet) and one Outlet Port (named outlet).
VariablesÂ¶
Stoichiometric reactors units add the following variables:
Variable  Name  Notes 

\(Q_t\)  heat  Only if has_heat_transfer = True, reference to control_volume.heat 
\(deltaP_t\)  pressure change  Only if has_pressure_change = True, reference to control_volume.deltaP 
ConstraintsÂ¶
Stoichiometric reactor units write no additional Constraints beyond those written by the control_volume Block.
StoichiometricReactor ClassÂ¶

class
idaes.unit_models.stoichiometric_reactor.
StoichiometricReactor
(*args, **kwargs)Â¶ Parameters:  rule (function) â€“ A rule function or None. Default rule calls build().
 concrete (bool) â€“ If True, make this a toplevel model. Default  False.
 ctype (str) â€“ Pyomo ctype of the block. Default  â€śBlockâ€ť
 default (dict) â€“
Default ProcessBlockData config
 Keys
 dynamic
 Indicates whether this model will be dynamic or not, default = useDefault. Valid values: { useDefault  get flag from parent (default = False), True  set as a dynamic model, False  set as a steadystate model.}
 has_holdup
 Indicates whether holdup terms should be constructed or not. Must be True if dynamic = True, default  False. Valid values: { True  construct holdup terms, False  do not construct holdup terms}
 material_balance_type
 Indicates what type of mass balance should be constructed, default  MaterialBalanceType.useDefault. Valid values: { MaterialBalanceType.useDefault  refer to property package for default balance type **MaterialBalanceType.none  exclude material balances, MaterialBalanceType.componentPhase  use phase component balances, MaterialBalanceType.componentTotal  use total component balances, MaterialBalanceType.elementTotal  use total element balances, MaterialBalanceType.total  use total material balance.}
 energy_balance_type
 Indicates what type of energy balance should be constructed, default  EnergyBalanceType.useDefault. Valid values: { EnergyBalanceType.useDefault  refer to property package for default balance type **EnergyBalanceType.none  exclude energy balances, EnergyBalanceType.enthalpyTotal  single enthalpy balance for material, EnergyBalanceType.enthalpyPhase  enthalpy balances for each phase, EnergyBalanceType.energyTotal  single energy balance for material, EnergyBalanceType.energyPhase  energy balances for each phase.}
 momentum_balance_type
 Indicates what type of momentum balance should be constructed, default  MomentumBalanceType.pressureTotal. Valid values: { MomentumBalanceType.none  exclude momentum balances, MomentumBalanceType.pressureTotal  single pressure balance for material, MomentumBalanceType.pressurePhase  pressure balances for each phase, MomentumBalanceType.momentumTotal  single momentum balance for material, MomentumBalanceType.momentumPhase  momentum balances for each phase.}
 has_heat_of_reaction
 Indicates whether terms for heat of reaction terms should be constructed, default  False. Valid values: { True  include heat of reaction terms, False  exclude heat of reaction terms.}
 has_heat_transfer
 Indicates whether terms for heat transfer should be constructed, default  False. Valid values: { True  include heat transfer terms, False  exclude heat transfer terms.}
 has_pressure_change
 Indicates whether terms for pressure change should be constructed, default  False. Valid values: { True  include pressure change terms, False  exclude pressure change terms.}
 property_package
 Property parameter object used to define property calculations, default  useDefault. Valid values: { useDefault  use default package from parent model or flowsheet, PropertyParameterObject  a PropertyParameterBlock object.}
 property_package_args
 A ConfigBlock with arguments to be passed to a property block(s) and used when constructing these, default  None. Valid values: { see property package for documentation.}
 reaction_package
 Reaction parameter object used to define reaction calculations, default  None. Valid values: { None  no reaction package, ReactionParameterBlock  a ReactionParameterBlock object.}
 reaction_package_args
 A ConfigBlock with arguments to be passed to a reaction block(s) and used when constructing these, default  None. Valid values: { see reaction package for documentation.}
 initialize (dict) â€“ ProcessBlockData config for individual elements. Keys are BlockData indexes and values are dictionaries described under the â€śdefaultâ€ť argument above.
 idx_map (function) â€“ Function to take the index of a BlockData element and return the index in the initialize dict from which to read arguments. This can be provided to overide the default behavior of matching the BlockData index exactly to the index in initialize.
Returns: (StoichiometricReactor) New instance
StoichiometricReactorData ClassÂ¶
Translator BlockÂ¶
Translator blocks are used in complex flowsheets where the user desires to use different property packages for different parts of the flowsheet. In order to link two streams using different property packages, a translator block is required.
The core translator block provides a general framework for constructing Translator Blocks, however users need to add constraints to map the incoming states to the outgoing states as required by their specific application.
Degrees of FreedomÂ¶
The degrees of freedom of Translator blocks depends on the property packages being used, and the user should write a sufficient number of constraints mapping inlet states to outlet states to satisfy these degrees of freedom.
Model StructureÂ¶
The core Translator Block consists of two State Blocks, names properties_in
and properties_out
, which are linked to two Ports names inlet
and outlet
respectively.
Additional ConstraintsÂ¶
The core Translator Block writes no additional constraints. Users should add constraints to their instances as required.
VariablesÂ¶
Translator blocks add no additional Variables.
Translator ClassÂ¶

class
idaes.unit_models.translator.
Translator
(*args, **kwargs)Â¶ Parameters:  rule (function) â€“ A rule function or None. Default rule calls build().
 concrete (bool) â€“ If True, make this a toplevel model. Default  False.
 ctype (str) â€“ Pyomo ctype of the block. Default  â€śBlockâ€ť
 default (dict) â€“
Default ProcessBlockData config
 Keys
 dynamic
 Translator blocks are always steadystate.
 has_holdup
 Translator blocks do not contain holdup.
 outlet_state_defined
 Indicates whether unit model will fully define outlet state. If False, the outlet property package will enforce constraints such as sum of mole fractions and phase equilibrium. default  True. Valid values: { True  outlet state will be fully defined, False  outlet property package should enforce sumation and equilibrium constraints.}
 has_phase_equilibrium
 Indicates whether outlet property package should enforce phase equilibrium constraints. default  False. Valid values: { True  outlet property package should calculate phase equilibrium, False  outlet property package should notcalculate phase equilibrium.}
 inlet_property_package
 Property parameter object used to define property calculations for the incoming stream, default  None. Valid values: { PhysicalParameterObject  a PhysicalParameterBlock object.}
 inlet_property_package_args
 A ConfigBlock with arguments to be passed to the property block associated with the incoming stream, default  None. Valid values: { see property package for documentation.}
 outlet_property_package
 Property parameter object used to define property calculations for the outgoing stream, default  None. Valid values: { PhysicalParameterObject  a PhysicalParameterBlock object.}
 outlet_property_package_args
 A ConfigBlock with arguments to be passed to the property block associated with the outgoing stream, default  None. Valid values: { see property package for documentation.}
 initialize (dict) â€“ ProcessBlockData config for individual elements. Keys are BlockData indexes and values are dictionaries described under the â€śdefaultâ€ť argument above.
 idx_map (function) â€“ Function to take the index of a BlockData element and return the index in the initialize dict from which to read arguments. This can be provided to overide the default behavior of matching the BlockData index exactly to the index in initialize.
Returns: (Translator) New instance
TranslatorData ClassÂ¶

class
idaes.unit_models.translator.
TranslatorData
(component)[source]Â¶ Standard Translator Block Class

initialize
(state_args_in={}, state_args_out={}, outlvl=0, solver='ipopt', optarg={'tol': 1e06})[source]Â¶ This method calls the initialization method of the state blocks.
Keyword Arguments:  state_args_in â€“ a dict of arguments to be passed to the inlet property package (to provide an initial state for initialization (see documentation of the specific property package) (default = {}).
 state_args_out â€“ a dict of arguments to be passed to the outlet property package (to provide an initial state for initialization (see documentation of the specific property package) (default = {}).
 outlvl â€“
sets output level of initialisation routine
 0 = no output (default)
 1 = return solver state for each step in routine
 2 = return solver state for each step in subroutines
 3 = include solver output infomation (tee=True)
 optarg â€“ solver options dictionary object (default={â€tolâ€™: 1e6})
 solver â€“ str indicating which solver to use during initialization (default = â€ipoptâ€™)
Returns: None

Power Generation ModelsÂ¶
Feedwater Heater (0D)Â¶
The FWH0D model is a 0D feedwater heater model suitable for steady state modeling. It is intended to be used primarily used with the IAWPS95 property package. The feedwater heater is split into three sections the condensing section is required while the desuperheating and drain cooling sections are optional. There is also an optional mixer for adding a drain stream from another feedwater heater to the condensing section. The figure below shows the layout of the feedwater heater. All but the condensing section are optional.
ExampleÂ¶
The example below shows how to setup a feedwater heater with all tree sections. The feedwater flow rate, steam conditions, heat transfer coefficients and areas are not necessarily realistic.
import pyomo.environ as pyo
from idaes.core import FlowsheetBlock
from idaes.unit_models.heat_exchanger import (delta_temperature_underwood_callback,
delta_temperature_lmtd_callback)
from idaes.property_models import iapws95
from idaes.unit_models.power_generation import FWH0D
def make_fwh_model():
model = pyo.ConcreteModel()
model.fs = FlowsheetBlock(default={
"dynamic": False,
"default_property_package": iapws95.Iapws95ParameterBlock()})
model.fs.properties = model.fs.config.default_property_package
model.fs.fwh = FWH0D(default={
"has_desuperheat":True,
"has_drain_cooling":True,
"has_drain_mixer":True,
"property_package":model.fs.properties})
model.fs.fwh.desuperheat.inlet_1.flow_mol.fix(100)
model.fs.fwh.desuperheat.inlet_1.flow_mol.unfix()
model.fs.fwh.desuperheat.inlet_1.pressure.fix(201325)
model.fs.fwh.desuperheat.inlet_1.enth_mol.fix(60000)
model.fs.fwh.drain_mix.drain.flow_mol.fix(1)
model.fs.fwh.drain_mix.drain.pressure.fix(201325)
model.fs.fwh.drain_mix.drain.enth_mol.fix(20000)
model.fs.fwh.cooling.inlet_2.flow_mol.fix(400)
model.fs.fwh.cooling.inlet_2.pressure.fix(101325)
model.fs.fwh.cooling.inlet_2.enth_mol.fix(3000)
model.fs.fwh.condense.area.fix(1000)
model.fs.fwh.condense.overall_heat_transfer_coefficient.fix(100)
model.fs.fwh.desuperheat.area.fix(1000)
model.fs.fwh.desuperheat.overall_heat_transfer_coefficient.fix(10)
model.fs.fwh.cooling.area.fix(1000)
model.fs.fwh.cooling.overall_heat_transfer_coefficient.fix(10)
model.fs.fwh.initialize()
return(model)
# create a feedwater heater model with all optional units and initialize
model = make_fwh_model()
Model StructureÂ¶
The condensing section uses the FWHCondensing0D model to calculate a steam flow rate such that all steam is condensed in the condensing section. This allows turbine steam extraction rates to be calculated. The other sections are regular HeatExchanger models. The table below shows the unit models which make up the feedwater heater, and the option to include or exclude them.
Unit  Option  Doc 

condense 
â€“  Condensing section (FWHCondensing0D) 
desuperheat 
has_desuperheat 
Desuperheating section (HeatExchanger) 
cooling 
has_drain_cooling 
Drain cooling section (HeatExchanger) 
drain_mix 
has_drain_mixer 
Mixer for steam and other FWH drain (Mixer) 
Degrees of FreedomÂ¶
The area
and overall_heat_transfer_coefficient
should be fixed or constraints should be provided to calculate overall_heat_transfer_coefficient
. If the inlets are also fixed except for the inlet steam flow rate (inlet_1.flow_mol
), the model will have 0 degrees of freedom.
See FWH0D
and FWH0DData
for full Python class details.
Feedwater Heater (Condensing Section 0D)Â¶
The condensing feedwater heater is the same as the HeatExchanger model with one additional constraint to calculate the inlet flow rate such that all the entering steam is condensed. This model is suitable for steady state modeling, and is intended to be used with the IAWPS95 property package. For dynamic modeling, the 1D feedwater heater models should be used (not yet publicly available).
Degrees of FreedomÂ¶
Usually area
and overall_heat_transfer_coefficient
are fixed or constraints are provided to calculate overall_heat_transfer_coefficient
. If the inlets are also fixed except for the inlet steam flow rate (inlet_1.flow_mol
), the model will have 0 degrees of freedom.
VariablesÂ¶
The variables are the same as HeatExchanger.
ConstraintsÂ¶
In addition to the HeatExchanger constraints, there is one additional constraint to calculate the inlet steam flow such that all steam condenses. The constraint is called extraction_rate_constraint
, and is defined below.
Where \(h\) is molar enthalpy, and the saturated liquid enthalpy is a function of pressure.
FWHCondensing0D ClassÂ¶

class
idaes.unit_models.power_generation.feedwater_heater_0D.
FWHCondensing0D
(*args, **kwargs)Â¶ Feedwater Heater Condensing Section The feedwater heater condensing section model is a normal 0D heat exchanger model with an added constraint to calculate the steam flow such that the outlet of shell is a saturated liquid.
 Args:
rule (function): A rule function or None. Default rule calls build(). concrete (bool): If True, make this a toplevel model. Default  False. ctype (str): Pyomo ctype of the block. Default  â€śBlockâ€ť default (dict): Default ProcessBlockData config
 Keys
 dynamic
 Indicates whether this model will be dynamic or not, default = useDefault. Valid values: { useDefault  get flag from parent (default = False), True  set as a dynamic model, False  set as a steadystate model.}
 has_holdup
 Indicates whether holdup terms should be constructed or not. Must be True if dynamic = True, default  False. Valid values: { True  construct holdup terms, False  do not construct holdup terms}
 hot_side_name
 Hot side name, sets control volume and inlet and outlet names
 cold_side_name
 Cold side name, sets control volume and inlet and outlet names
 hot_side_config
A config block used to construct the hot side control volume. This config can be given by the hot side name instead of hot_side_config.
 material_balance_type
 Indicates what type of mass balance should be constructed, default  MaterialBalanceType.useDefault. Valid values: { MaterialBalanceType.useDefault  refer to property package for default balance type **MaterialBalanceType.none  exclude material balances, MaterialBalanceType.componentPhase  use phase component balances, MaterialBalanceType.componentTotal  use total component balances, MaterialBalanceType.elementTotal  use total element balances, MaterialBalanceType.total  use total material balance.}
 energy_balance_type
 Indicates what type of energy balance should be constructed, default  EnergyBalanceType.useDefault. Valid values: { EnergyBalanceType.useDefault  refer to property package for default balance type **EnergyBalanceType.none  exclude energy balances, EnergyBalanceType.enthalpyTotal  single enthalpy balance for material, EnergyBalanceType.enthalpyPhase  enthalpy balances for each phase, EnergyBalanceType.energyTotal  single energy balance for material, EnergyBalanceType.energyPhase  energy balances for each phase.}
 momentum_balance_type
 Indicates what type of momentum balance should be constructed, default  MomentumBalanceType.pressureTotal. Valid values: { MomentumBalanceType.none  exclude momentum balances, MomentumBalanceType.pressureTotal  single pressure balance for material, MomentumBalanceType.pressurePhase  pressure balances for each phase, MomentumBalanceType.momentumTotal  single momentum balance for material, MomentumBalanceType.momentumPhase  momentum balances for each phase.}
 has_phase_equilibrium
 Indicates whether terms for phase equilibrium should be constructed, default = False. Valid values: { True  include phase equilibrium terms False  exclude phase equilibrium terms.}
 has_pressure_change
 Indicates whether terms for pressure change should be constructed, default  False. Valid values: { True  include pressure change terms, False  exclude pressure change terms.}
 property_package
 Property parameter object used to define property calculations, default  useDefault. Valid values: { useDefault  use default package from parent model or flowsheet, PropertyParameterObject  a PropertyParameterBlock object.}
 property_package_args
 A ConfigBlock with arguments to be passed to a property block(s) and used when constructing these, default  None. Valid values: { see property package for documentation.}
 cold_side_config
A config block used to construct the cold side control volume. This config can be given by the cold side name instead of cold_side_config.
 material_balance_type
 Indicates what type of mass balance should be constructed, default  MaterialBalanceType.useDefault. Valid values: { MaterialBalanceType.useDefault  refer to property package for default balance type **MaterialBalanceType.none  exclude material balances, MaterialBalanceType.componentPhase  use phase component balances, MaterialBalanceType.componentTotal  use total component balances, MaterialBalanceType.elementTotal  use total element balances, MaterialBalanceType.total  use total material balance.}
 energy_balance_type
 Indicates what type of energy balance should be constructed, default  EnergyBalanceType.useDefault. Valid values: { EnergyBalanceType.useDefault  refer to property package for default balance type **EnergyBalanceType.none  exclude energy balances, EnergyBalanceType.enthalpyTotal  single enthalpy balance for material, EnergyBalanceType.enthalpyPhase  enthalpy balances for each phase, EnergyBalanceType.energyTotal  single energy balance for material, EnergyBalanceType.energyPhase  energy balances for each phase.}
 momentum_balance_type
 Indicates what type of momentum balance should be constructed, default  MomentumBalanceType.pressureTotal. Valid values: { MomentumBalanceType.none  exclude momentum balances, MomentumBalanceType.pressureTotal  single pressure balance for material, MomentumBalanceType.pressurePhase  pressure balances for each phase, MomentumBalanceType.momentumTotal  single momentum balance for material, MomentumBalanceType.momentumPhase  momentum balances for each phase.}
 has_phase_equilibrium
 Indicates whether terms for phase equilibrium should be constructed, default = False. Valid values: { True  include phase equilibrium terms False  exclude phase equilibrium terms.}
 has_pressure_change
 Indicates whether terms for pressure change should be constructed, default  False. Valid values: { True  include pressure change terms, False  exclude pressure change terms.}
 property_package
 Property parameter object used to define property calculations, default  useDefault. Valid values: { useDefault  use default package from parent model or flowsheet, PropertyParameterObject  a PropertyParameterBlock object.}
 property_package_args
 A ConfigBlock with arguments to be passed to a property block(s) and used when constructing these, default  None. Valid values: { see property package for documentation.}
 delta_temperature_callback
 Callback for for temperature difference calculations
 flow_pattern
 Heat exchanger flow pattern, default  HeatExchangerFlowPattern.countercurrent. Valid values: { HeatExchangerFlowPattern.countercurrent  countercurrent flow, HeatExchangerFlowPattern.cocurrent  cocurrent flow, HeatExchangerFlowPattern.crossflow  cross flow, factor times countercurrent temperature difference.}
 initialize (dict): ProcessBlockData config for individual elements. Keys
 are BlockData indexes and values are dictionaries described under the â€śdefaultâ€ť argument above.
 idx_map (function): Function to take the index of a BlockData element and
 return the index in the initialize dict from which to read arguments. This can be provided to overide the default behavior of matching the BlockData index exactly to the index in initialize.
 Returns:
 (FWHCondensing0D) New instance
Turbine (Inlet Stage)Â¶
This is a steam power generation turbine model for the inlet stage. The turbine inlet model is based on:
Liese, (2014). â€śModeling of a Steam Turbine Including Partial Arc Admission for Use in a Process Simulation Software Environment.â€ť Journal of Engineering for Gas Turbines and Power. v136.
ExampleÂ¶
from pyomo.environ import ConcreteModel, SolverFactory, TransformationFactory
from idaes.core import FlowsheetBlock
from idaes.unit_models.power_generation import TurbineInletStage
from idaes.property_models import iapws95
m = ConcreteModel()
m.fs = FlowsheetBlock(default={"dynamic": False})
m.fs.properties = iapws95.Iapws95ParameterBlock()
m.fs.turb = TurbineInletStage(default={"property_package": m.fs.properties})
hin = iapws95.htpx(T=880, P=2.4233e7)
# set inlet
m.fs.turb.inlet[:].enth_mol.fix(hin)
m.fs.turb.inlet[:].flow_mol.fix(26000/4.0)
m.fs.turb.inlet[:].pressure.fix(2.4233e7)
m.fs.turb.eff_nozzle.fix(0.95)
m.fs.turb.blade_reaction.fix(0.9)
m.fs.turb.flow_coeff.fix(1.053/3600.0)
m.fs.turb.blade_velocity.fix(110.0)
m.fs.turb.efficiency_mech.fix(0.98)
m.fs.turb.initialize()
Degrees of FreedomÂ¶
Usually the inlet stream, or the inlet stream minus flow rate plus discharge pressure are fixed. There are also a few variables which are turbine parameters and are usually fixed. See the variables section for more information.
Model StructureÂ¶
The turbine inlet stage model contains one ControlVolume0DBlock block called control_volume and inherits the PressureChanger model using the isentropic option.
VariablesÂ¶
The variables below are defined in the TurbineInletStage model. Additional variables are inherited from the PressureChanger model model.
Variable  Symbol  Index Sets  Doc 

blade_reaction 
\(R\)  None  Blade reaction 
eff_nozzle 
\(\eta_{nozzle}\)  None  Nozzle efficiency 
efficiency_mech 
\(\eta_{mech}\)  None  Mechanical Efficiency (accounts for losses in bearingsâ€¦) 
flow_coeff 
\(C_{flow}\)  None  Turbine stage flow coefficient [kg*C^0.5/Pa/s] 
blade_velocity 
\(V_{rbl}\)  None  Turbine blade velocity (should be constant while running) [m/s] 
delta_enth_isentropic 
\(\Delta h_{isen}\)  time  Isentropic enthalpy change through stage [J/mol] 
The table below shows important variables inherited from the pressure changer model.
Variable  Symbol  Index Sets  Doc 

efficiency_isentropic 
\(\eta_{isen}\)  time  Isentropic efficiency 
deltaP 
\(\Delta P\)  time  Pressure change (\(P_{out}  P_{in}\)) [Pa] 
ratioP 
\(P_{ratio}\)  time  Ratio of discharge pressure to inlet pressure \(\left(\frac{P_{out}}{P_{in}}\right)\) 
ExpressionsÂ¶
Variable  Symbol  Index Sets  Doc 

power_thermo 
\(\dot{w}_{thermo}\)  time  Turbine stage power output not including mechanical loss [W] 
power_shaft 
\(\dot{w}_{shaft}\)  time  Turbine stage power output including mechanical loss (bearingsâ€¦) [W] 
steam_entering_velocity 
\(V_0\)  time  Steam velocity entering stage [m/s] 
The expression defined below provides a calculation for steam velocity entering the stage, which is used in the efficiency calculation.
ConstraintsÂ¶
In addition to the constraints inherited from the PressureChanger model with the isentropic options, this model contains two more constraints, one to estimate efficiency and one pressureflow relation. From the isentropic pressure changer model, these constraints eliminate the need to specify efficiency and either inlet flow or outlet pressure.
The isentropic efficiency is given by:
The pressureflow relation is given by:
InitializationÂ¶
The initialization method for this model will save the current state of the model
before commencing initialization and reloads it afterwards. The state of the model
will be the same after initialization, only the initial guesses for
unfixed variables will be changed. To initialize this model, provide a starting
value for the inlet port variables. Then provide a guess for one of: discharge
pressure, deltaP
, or ratioP
.
The model should initialize readily, but it is possible to provide a flow coefficient that is incompatible with the given flow rate resulting in an infeasible problem.
TurbineInletStage ClassÂ¶

class
idaes.unit_models.power_generation.turbine_inlet.
TurbineInletStage
(*args, **kwargs)Â¶ Inlet stage steam turbine model
Parameters:  rule (function) â€“ A rule function or None. Default rule calls build().
 concrete (bool) â€“ If True, make this a toplevel model. Default  False.
 ctype (str) â€“ Pyomo ctype of the block. Default  â€śBlockâ€ť
 default (dict) â€“
Default ProcessBlockData config
 Keys
 dynamic
 Indicates whether this model will be dynamic or not, default = useDefault. Valid values: { useDefault  get flag from parent (default = False), True  set as a dynamic model, False  set as a steadystate model.}
 has_holdup
 Indicates whether holdup terms should be constructed or not. Must be True if dynamic = True, default  False. Valid values: { True  construct holdup terms, False  do not construct holdup terms}
 material_balance_type
 Indicates what type of mass balance should be constructed, default  MaterialBalanceType.useDefault. Valid values: { MaterialBalanceType.useDefault  refer to property package for default balance type **MaterialBalanceType.none  exclude material balances, MaterialBalanceType.componentPhase  use phase component balances, MaterialBalanceType.componentTotal  use total component balances, MaterialBalanceType.elementTotal  use total element balances, MaterialBalanceType.total  use total material balance.}
 energy_balance_type
 Indicates what type of energy balance should be constructed, default  EnergyBalanceType.useDefault. Valid values: { EnergyBalanceType.useDefault  refer to property package for default balance type **EnergyBalanceType.none  exclude energy balances, EnergyBalanceType.enthalpyTotal  single enthalpy balance for material, EnergyBalanceType.enthalpyPhase  enthalpy balances for each phase, EnergyBalanceType.energyTotal  single energy balance for material, EnergyBalanceType.energyPhase  energy balances for each phase.}
 momentum_balance_type
 Indicates what type of momentum balance should be constructed, default  MomentumBalanceType.pressureTotal. Valid values: { MomentumBalanceType.none  exclude momentum balances, MomentumBalanceType.pressureTotal  single pressure balance for material, MomentumBalanceType.pressurePhase  pressure balances for each phase, MomentumBalanceType.momentumTotal  single momentum balance for material, MomentumBalanceType.momentumPhase  momentum balances for each phase.}
 has_phase_equilibrium
 Indicates whether terms for phase equilibrium should be constructed, default = False. Valid values: { True  include phase equilibrium terms False  exclude phase equilibrium terms.}
 compressor
 Indicates whether this unit should be considered a compressor (True (default), pressure increase) or an expander (False, pressure decrease).
 thermodynamic_assumption
 Flag to set the thermodynamic assumption to use for the unit.  ThermodynamicAssumption.isothermal (default)  ThermodynamicAssumption.isentropic  ThermodynamicAssumption.pump  ThermodynamicAssumption.adiabatic
 property_package
 Property parameter object used to define property calculations, default  useDefault. Valid values: { useDefault  use default package from parent model or flowsheet, PropertyParameterObject  a PropertyParameterBlock object.}
 property_package_args
 A ConfigBlock with arguments to be passed to a property block(s) and used when constructing these, default  None. Valid values: { see property package for documentation.}
 initialize (dict) â€“ ProcessBlockData config for individual elements. Keys are BlockData indexes and values are dictionaries described under the â€śdefaultâ€ť argument above.
 idx_map (function) â€“ Function to take the index of a BlockData element and return the index in the initialize dict from which to read arguments. This can be provided to overide the default behavior of matching the BlockData index exactly to the index in initialize.
Returns: (TurbineInletStage) New instance
TurbineInletStageData ClassÂ¶

class
idaes.unit_models.power_generation.turbine_inlet.
TurbineInletStageData
(component)[source]Â¶
Turbine (Outlet Stage)Â¶
This is a steam power generation turbine model for the outlet stage. The turbine outlet model is based on:
Liese, (2014). â€śModeling of a Steam Turbine Including Partial Arc Admission for Use in a Process Simulation Software Environment.â€ť Journal of Engineering for Gas Turbines and Power. v136.
ExampleÂ¶
from pyomo.environ import ConcreteModel, SolverFactory
from idaes.core import FlowsheetBlock
from idaes.unit_models.power_generation import TurbineOutletStage
from idaes.property_models import iapws95
m = ConcreteModel()
m.fs = FlowsheetBlock(default={"dynamic": False})
m.fs.properties = iapws95.Iapws95ParameterBlock()
m.fs.turb = TurbineOutletStage(default={"property_package": m.fs.properties})
# set inlet
m.fs.turb.inlet[:].enth_mol.fix(47115)
m.fs.turb.inlet[:].flow_mol.fix(15000)
m.fs.turb.inlet[:].pressure.fix(8e4)
m.fs.turb.initialize()
Degrees of FreedomÂ¶
Usually the inlet stream, or the inlet stream minus flow rate plus discharge pressure are fixed. There are also a few variables which are turbine parameters and are usually fixed. See the variables section for more information.
Model StructureÂ¶
The turbine outlet stage model contains one ControlVolume0DBlock block called control_volume and inherits the PressureChanger model using the isentropic option.
VariablesÂ¶
The variables below are defined int the TurbineInletStage model. Additional variables are in inherited from the PressureChanger model model.
Variable  Symbol  Index Sets  Doc 

eff_dry 
\(\eta_{dry}\)  None  Turbine efficiency when no liquid is present. 
efficiency_mech 
\(\eta_{mech}\)  None  Mechanical Efficiency (accounts for losses in bearingsâ€¦) 
flow_coeff 
\(C_{flow}\)  None  Turbine stage flow coefficient [kg*C^0.5/Pa/s] 
design_exhaust_flow_vol 
\(V_{des,exhaust}\)  None  Design volumetric flow out of stage [m^3/s] 
The table below shows important variables inherited from the pressure changer model.
Variable  Symbol  Index Sets  Doc 

efficiency_isentropic 
\(\eta_{isen}\)  time  Isentropic efficiency 
deltaP 
\(\Delta P\)  time  Pressure change (\(P_{out}  P_{in}\)) [Pa] 
ratioP 
\(P_{ratio}\)  time  Ratio of discharge pressure to inlet pressure \(\left(\frac{P_{out}}{P_{in}}\right)\) 
ExpressionsÂ¶
Variable  Symbol  Index Sets  Doc 

power_thermo 
\(\dot{w}_{thermo}\)  time  Turbine stage power output not including mechanical loss [W] 
power_shaft 
\(\dot{w}_{shaft}\)  time  Turbine stage power output including mechanical loss (bearingsâ€¦) [W] 
tel 
\(\text{TEL}\)  time  Total exhaust loss [J/mol] 
The expression defined below provides a total exhaust loss.
Where \(f\) is the total volumetric flow of the exhaust divided by the design flow.
ConstraintsÂ¶
In addition to the constraints inherited from the PressureChanger model with the isentropic options, this model contains two more constraints, one to estimate efficiency and one pressureflow relation. From the isentropic pressure changer model, these constraints eliminate the need to specify efficiency and either inlet flow or outlet pressure.
The isentropic efficiency is given by:
Where \(x\) is the steam quality (vapor fraction).
The pressureflow relation is given by the Stodola Equation:
InitializationÂ¶
The initialization method for this model will save the current state of the model
before commencing initialization and reloads it afterwards. The state of the model
will be the same after initialization, only the initial guesses for
unfixed variables will be changed. To initialize this model, provide a starting
value for the inlet port variables. Then provide a guess for one of: discharge
pressure, deltaP
, or ratioP
.
The model should initialize readily, but it is possible to provide a flow coefficient that is incompatible with the given flow rate resulting in an infeasible problem.
TurbineOutletStage ClassÂ¶

class
idaes.unit_models.power_generation.turbine_outlet.
TurbineOutletStage
(*args, **kwargs)Â¶ Outlet stage steam turbine model
Parameters:  rule (function) â€“ A rule function or None. Default rule calls build().
 concrete (bool) â€“ If True, make this a toplevel model. Default  False.
 ctype (str) â€“ Pyomo ctype of the block. Default  â€śBlockâ€ť
 default (dict) â€“
Default ProcessBlockData config
 Keys
 dynamic
 Indicates whether this model will be dynamic or not, default = useDefault. Valid values: { useDefault  get flag from parent (default = False), True  set as a dynamic model, False  set as a steadystate model.}
 has_holdup
 Indicates whether holdup terms should be constructed or not. Must be True if dynamic = True, default  False. Valid values: { True  construct holdup terms, False  do not construct holdup terms}
 material_balance_type
 Indicates what type of mass balance should be constructed, default  MaterialBalanceType.useDefault. Valid values: { MaterialBalanceType.useDefault  refer to property package for default balance type **MaterialBalanceType.none  exclude material balances, MaterialBalanceType.componentPhase  use phase component balances, MaterialBalanceType.componentTotal  use total component balances, MaterialBalanceType.elementTotal  use total element balances, MaterialBalanceType.total  use total material balance.}
 energy_balance_type
 Indicates what type of energy balance should be constructed, default  EnergyBalanceType.useDefault. Valid values: { EnergyBalanceType.useDefault  refer to property package for default balance type **EnergyBalanceType.none  exclude energy balances, EnergyBalanceType.enthalpyTotal  single enthalpy balance for material, EnergyBalanceType.enthalpyPhase  enthalpy balances for each phase, EnergyBalanceType.energyTotal  single energy balance for material, EnergyBalanceType.energyPhase  energy balances for each phase.}
 momentum_balance_type
 Indicates what type of momentum balance should be constructed, default  MomentumBalanceType.pressureTotal. Valid values: { MomentumBalanceType.none  exclude momentum balances, MomentumBalanceType.pressureTotal  single pressure balance for material, MomentumBalanceType.pressurePhase  pressure balances for each phase, MomentumBalanceType.momentumTotal  single momentum balance for material, MomentumBalanceType.momentumPhase  momentum balances for each phase.}
 has_phase_equilibrium
 Indicates whether terms for phase equilibrium should be constructed, default = False. Valid values: { True  include phase equilibrium terms False  exclude phase equilibrium terms.}
 compressor
 Indicates whether this unit should be considered a compressor (True (default), pressure increase) or an expander (False, pressure decrease).
 thermodynamic_assumption
 Flag to set the thermodynamic assumption to use for the unit.  ThermodynamicAssumption.isothermal (default)  ThermodynamicAssumption.isentropic  ThermodynamicAssumption.pump  ThermodynamicAssumption.adiabatic
 property_package
 Property parameter object used to define property calculations, default  useDefault. Valid values: { useDefault  use default package from parent model or flowsheet, PropertyParameterObject  a PropertyParameterBlock object.}
 property_package_args
 A ConfigBlock with arguments to be passed to a property block(s) and used when constructing these, default  None. Valid values: { see property package for documentation.}
 initialize (dict) â€“ ProcessBlockData config for individual elements. Keys are BlockData indexes and values are dictionaries described under the â€śdefaultâ€ť argument above.
 idx_map (function) â€“ Function to take the index of a BlockData element and return the index in the initialize dict from which to read arguments. This can be provided to overide the default behavior of matching the BlockData index exactly to the index in initialize.
Returns: (TurbineOutletStage) New instance
TurbineOutletStageData ClassÂ¶

class
idaes.unit_models.power_generation.turbine_outlet.
TurbineOutletStageData
(component)[source]Â¶
Turbine (Stage)Â¶
This is a steam power generation turbine model for the stages between the inlet and outlet. This model inherits the PressureChanger model with the isentropic options. The initialization scheme is the same as the TurbineInletStage model.
ExampleÂ¶
from pyomo.environ import ConcreteModel, SolverFactory
from idaes.core import FlowsheetBlock
from idaes.unit_models.power_generation import TurbineStage
from idaes.property_models import iapws95
m = ConcreteModel()
m.fs = FlowsheetBlock(default={"dynamic": False})
m.fs.properties = iapws95.Iapws95ParameterBlock()
m.fs.turb = TurbineStage(default={"property_package": m.fs.properties})
# set inlet
m.fs.turb.inlet[:].enth_mol.fix(70000)
m.fs.turb.inlet[:].flow_mol.fix(15000)
m.fs.turb.inlet[:].pressure.fix(8e6)
m.fs.turb.efficiency_isentropic[:].fix(0.8)
m.fs.turb.ratioP[:].fix(0.7)
m.fs.turb.initialize()
VariablesÂ¶
This model adds a variable to the base PressureChanger model
to account
for mechanical efficiency .
Variable  Symbol  Index Sets  Doc 

efficiency_mech 
\(\eta_{mech}\)  None  Mechanical Efficiency (accounts for losses in bearingsâ€¦) 
The table below shows important variables inherited from the pressure changer model.
Variable  Symbol  Index Sets  Doc 

efficiency_isentropic 
\(\eta_{isen}\)  time  Isentropic efficiency 
deltaP 
\(\Delta P\)  time  Pressure change (\(P_{out}  P_{in}\)) [Pa] 
ratioP 
\(P_{ratio}\)  time  Ratio of discharge pressure to inlet pressure \(\left(\frac{P_{out}}{P_{in}}\right)\) 
\(\eta_{isentropic,t}\) efficiency_isentropic Isentropic assumption only
ExpressionsÂ¶
This model provides two expressions that are not available in the pressure changer model.
Variable  Symbol  Index Sets  Doc 

power_thermo 
\(\dot{w}_{thermo}\)  time  Turbine stage power output not including mechanical loss [W] 
power_shaft 
\(\dot{w}_{shaft}\)  time  Turbine stage power output including mechanical loss (bearingsâ€¦) [W] 
ConstraintsÂ¶
There are no additional constraints.
InitializationÂ¶
This just calls the initialization routine from PressureChanger
, but it is wrapped in
a function to ensure the state after initialization is the same as before initialization.
The arguments to the initialization method are the same as PressureChanger.
TurbineStage ClassÂ¶

class
idaes.unit_models.power_generation.turbine_stage.
TurbineStage
(*args, **kwargs)Â¶ Basic steam turbine model
Parameters:  rule (function) â€“ A rule function or None. Default rule calls build().
 concrete (bool) â€“ If True, make this a toplevel model. Default  False.
 ctype (str) â€“ Pyomo ctype of the block. Default  â€śBlockâ€ť
 default (dict) â€“
Default ProcessBlockData config
 Keys
 dynamic
 Indicates whether this model will be dynamic or not, default = useDefault. Valid values: { useDefault  get flag from parent (default = False), True  set as a dynamic model, False  set as a steadystate model.}
 has_holdup
 Indicates whether holdup terms should be constructed or not. Must be True if dynamic = True, default  False. Valid values: { True  construct holdup terms, False  do not construct holdup terms}
 material_balance_type
 Indicates what type of mass balance should be constructed, default  MaterialBalanceType.useDefault. Valid values: { MaterialBalanceType.useDefault  refer to property package for default balance type **MaterialBalanceType.none  exclude material balances, MaterialBalanceType.componentPhase  use phase component balances, MaterialBalanceType.componentTotal  use total component balances, MaterialBalanceType.elementTotal  use total element balances, MaterialBalanceType.total  use total material balance.}
 energy_balance_type
 Indicates what type of energy balance should be constructed, default  EnergyBalanceType.useDefault. Valid values: { EnergyBalanceType.useDefault  refer to property package for default balance type **EnergyBalanceType.none  exclude energy balances, EnergyBalanceType.enthalpyTotal  single enthalpy balance for material, EnergyBalanceType.enthalpyPhase  enthalpy balances for each phase, EnergyBalanceType.energyTotal  single energy balance for material, EnergyBalanceType.energyPhase  energy balances for each phase.}
 momentum_balance_type
 Indicates what type of momentum balance should be constructed, default  MomentumBalanceType.pressureTotal. Valid values: { MomentumBalanceType.none  exclude momentum balances, MomentumBalanceType.pressureTotal  single pressure balance for material, MomentumBalanceType.pressurePhase  pressure balances for each phase, MomentumBalanceType.momentumTotal  single momentum balance for material, MomentumBalanceType.momentumPhase  momentum balances for each phase.}
 has_phase_equilibrium
 Indicates whether terms for phase equilibrium should be constructed, default = False. Valid values: { True  include phase equilibrium terms False  exclude phase equilibrium terms.}
 compressor
 Indicates whether this unit should be considered a compressor (True (default), pressure increase) or an expander (False, pressure decrease).
 thermodynamic_assumption
 Flag to set the thermodynamic assumption to use for the unit.  ThermodynamicAssumption.isothermal (default)  ThermodynamicAssumption.isentropic  ThermodynamicAssumption.pump  ThermodynamicAssumption.adiabatic
 property_package
 Property parameter object used to define property calculations, default  useDefault. Valid values: { useDefault  use default package from parent model or flowsheet, PropertyParameterObject  a PropertyParameterBlock object.}
 property_package_args
 A ConfigBlock with arguments to be passed to a property block(s) and used when constructing these, default  None. Valid values: { see property package for documentation.}
 initialize (dict) â€“ ProcessBlockData config for individual elements. Keys are BlockData indexes and values are dictionaries described under the â€śdefaultâ€ť argument above.
 idx_map (function) â€“ Function to take the index of a BlockData element and return the index in the initialize dict from which to read arguments. This can be provided to overide the default behavior of matching the BlockData index exactly to the index in initialize.
Returns: (TurbineStage) New instance
TurbineStageData ClassÂ¶

class
idaes.unit_models.power_generation.turbine_stage.
TurbineStageData
(component)[source]Â¶
Turbine (Multistage)Â¶
This is a composite model for a power plant turbine with high, intermediate and low pressure sections. This model contains an inlet stage with throttle valves for partial arc admission and optional splitters for steam extraction.
The figure below shows the layout of the mutistage turbine model. Optional splitters provide for steam extraction. The splitters can have two or more outlets (one being the main steam outlet). The streams that connect one stage to the next can also be omitted. This allows for connecting additional unit models (usually reheaters) between stages.
ExampleÂ¶
This example sets up a turbine multistage turbine model similar to what could be found in a power plant steam cycle. There are 7 highpressure stages, 14 intermediatepressure stages, and 11 lowpressure stages. Steam extractions are provided after stages hp4, hp7, ip5, ip14, lp4, lp7, lp9, lp11. The extraction at ip14 uses a splitter with three outlets, one for the main steam, one for the boiler feed pump, and one for a feedwater heater. There is a disconnection between the HP and IP sections so that steam can be sent to a reheater. In this example, a heater block is a standin for a reheater model.
from pyomo.environ import (ConcreteModel, SolverFactory, TransformationFactory,
Constraint, value)
from pyomo.network import Arc
from idaes.core import FlowsheetBlock
from idaes.unit_models import Heater
from idaes.unit_models.power_generation import (
TurbineMultistage, TurbineStage, TurbineInletStage, TurbineOutletStage)
from idaes.property_models import iapws95
solver = SolverFactory('ipopt')
solver.options = {'tol': 1e6}
m = ConcreteModel()
m.fs = FlowsheetBlock(default={"dynamic": False})
m.fs.properties = iapws95.Iapws95ParameterBlock()
m.fs.turb = TurbineMultistage(default={
"property_package": m.fs.properties,
"num_hp": 7,
"num_ip": 14,
"num_lp": 11,
"hp_split_locations": [4,7],
"ip_split_locations": [5, 14],
"lp_split_locations": [4,7,9,11],
"hp_disconnect": [7], # 7 is last stage in hp so disconnect hp from ip
"ip_split_num_outlets": {14:3}})
# Add reheater (for example using a simple heater block)
m.fs.reheat = Heater(default={"property_package": m.fs.properties})
# Add Arcs (streams) to connect the HP and IP sections through reheater
m.fs.hp_to_reheat = Arc(source=m.fs.turb.hp_split[7].outlet_1,
destination=m.fs.reheat.inlet)
m.fs.reheat_to_ip = Arc(source=m.fs.reheat.outlet,
destination=m.fs.turb.ip_stages[1].inlet)
# Set the turbine inlet conditions and an initial flow guess
p = 2.4233e7
hin = iapws95.htpx(T=880, P=p)
m.fs.turb.inlet_split.inlet.enth_mol[0].fix(hin)
m.fs.turb.inlet_split.inlet.flow_mol[0].fix(26000)
m.fs.turb.inlet_split.inlet.pressure[0].fix(p)
# Set the inlet of the ip section for initialization, since it is disconnected
p = 7.802e+06
hin = iapws95.htpx(T=880, P=p)
m.fs.turb.ip_stages[1].inlet.enth_mol[0].value = hin
m.fs.turb.ip_stages[1].inlet.flow_mol[0].value = 25220.0
m.fs.turb.ip_stages[1].inlet.pressure[0].value = p
# Set the efficency and pressure ratios of stages other than inlet and outlet
for i, s in turb.hp_stages.items():
s.ratioP[:] = 0.88
s.efficiency_isentropic[:] = 0.9
for i, s in turb.ip_stages.items():
s.ratioP[:] = 0.85
s.efficiency_isentropic[:] = 0.9
for i, s in turb.lp_stages.items():
s.ratioP[:] = 0.82
s.efficiency_isentropic[:] = 0.9
# Usually these fractions would be determined by the boiler feed water heater
# network. Since this example doesn't include them, just fix split fractions
turb.hp_split[4].split_fraction[0,"outlet_2"].fix(0.03)
turb.hp_split[7].split_fraction[0,"outlet_2"].fix(0.03)
turb.ip_split[5].split_fraction[0,"outlet_2"].fix(0.04)
turb.ip_split[14].split_fraction[0,"outlet_2"].fix(0.04)
turb.ip_split[14].split_fraction[0,"outlet_3"].fix(0.15)
turb.lp_split[4].split_fraction[0,"outlet_2"].fix(0.04)
turb.lp_split[7].split_fraction[0,"outlet_2"].fix(0.04)
turb.lp_split[9].split_fraction[0,"outlet_2"].fix(0.04)
turb.lp_split[11].split_fraction[0,"outlet_2"].fix(0.04)
# unfix inlet flow for pressure driven simulation
turb.inlet_split.inlet.flow_mol.unfix()
# Set the inlet steam mixer to use the constraints that the pressures of all
# inlet streams are equal
turb.inlet_mix.use_equal_pressure_constraint()
# Initialize turbine
turb.initialize(outlvl=1)
# Copy conditions out of turbine to initialize the reheater
for t in m.fs.time:
m.fs.reheat.inlet.flow_mol[t].value = \
value(turb.hp_split[7].outlet_1_state[t].flow_mol)
m.fs.reheat.inlet.enth_mol[t].value = \
value(turb.hp_split[7].outlet_1_state[t].enth_mol)
m.fs.reheat.inlet.pressure[t].value = \
value(turb.hp_split[7].outlet_1_state[t].pressure)
# initialize the reheater
m.fs.reheat.initialize(outlvl=4)
# Add constraint to the reheater to result in 880K outlet temperature
def reheat_T_rule(b, t):
return m.fs.reheat.control_volume.properties_out[t].temperature == 880
m.fs.reheat.temperature_out_equation = Constraint(m.fs.reheat.time_ref,
rule=reheat_T_rule)
# Expand the Arcs connecting the turbine to the reheater
TransformationFactory("network.expand_arcs").apply_to(m)
# Fix the outlet pressure (usually determined by condenser)
m.fs.turb.outlet_stage.control_volume.properties_out[0].pressure.fix()
# Solve the pressure driven flow model with reheat
solver.solve(m, tee=True)
Unit ModelsÂ¶
The multistage turbine model contains the models in the table below. The splitters for steam extraction are not present if a turbine section contains no steam extractions.
Unit  Index Sets  Doc 

inlet_split 
None  Splitter to split the main steam feed into steams for each arc (Separator) 
throttle_valve 
Admission Arcs  Throttle valves for each admission arc (SteamValve) 
inlet_stage 
Admission Arcs  Parallel inlet turbine stages that represent admission arcs (TurbineInlet) 
inlet_mix 
None  Mixer to combine the streams from each arc back to one stream (Mixer) 
hp_stages 
HP stages  Turbine stages in the highpressure section (TurbineStage) 
ip_stages 
IP stages  Turbine stages in the intermediatepressure section (TurbineStage) 
lp_stages 
LP stages  Turbine stages in the lowpressure section (TurbineStage) 
hp_splits 
subset of HP stages  Extraction splitters in the highpressure section (Separator) 
ip_splits 
subset of IP stages  Extraction splitters in the highpressure section (Separator) 
lp_splits 
subset of LP stages  Extraction splitters in the highpressure section (Separator) 
outlet_stage 
None  The final stage in the turbine, which calculates exhaust losses (TurbineOutlet) 
InitializationÂ¶
The initialization approach is to sequentially initialize each subunit using the outlet of the previous model. Before initializing the model, the inlet of the turbine, and any stage that is disconnected should be given a reasonable guess. The efficiency and pressure ration of the stages in the HP, IP and LP sections should be specified. For the inlet and outlet stages the flow coefficient should be specified. Valve coefficients should also be specified. A reasonable guess for split fractions should also be given for any extraction splitters present. The most likely cause of initialization failure is flow coefficients in inlet stage, outlet stage, or valves that do not pair well with the specified flow rates.
TurbineMultistage ClassÂ¶

class
idaes.unit_models.power_generation.turbine_multistage.
TurbineMultistage
(*args, **kwargs)Â¶ Multistage steam turbine with optional reheat and extraction
Parameters:  rule (function) â€“ A rule function or None. Default rule calls build().
 concrete (bool) â€“ If True, make this a toplevel model. Default  False.
 ctype (str) â€“ Pyomo ctype of the block. Default  â€śBlockâ€ť
 default (dict) â€“
Default ProcessBlockData config
 Keys
 dynamic
 Indicates whether the model is dynamic.
 has_holdup
 Indicates whether holdup terms should be constructed or not. Must be True if dynamic = True, default  False. Valid values: { True  construct holdup terms, False  do not construct holdup terms}
 has_phase_equilibrium
 Argument indicating whether phase equilibrium should be calculated for the resulting mixed stream, default  False. Valid values: { True  calculate phase equilibrium in mixed stream, False  do not calculate equilibrium in mixed stream.}
 material_balance_type
 Indicates what type of mass balance should be constructed, default  MaterialBalanceType.componentTotal`. Valid values: { MaterialBalanceType.none  exclude material balances, MaterialBalanceType.componentPhase  use phase component balances, MaterialBalanceType.componentTotal  use total component balances, MaterialBalanceType.elementTotal  use total element balances, MaterialBalanceType.total  use total material balance.}
 property_package
 Property parameter object used to define property calculations, default  useDefault. Valid values: { useDefault  use default package from parent model or flowsheet, PropertyParameterObject  a PropertyParameterBlock object.}
 property_package_args
 A ConfigBlock with arguments to be passed to a property block(s) and used when constructing these, default  None. Valid values: { see property package for documentation.}
 num_parallel_inlet_stages
 Number of parallel inlet stages to simulate partial arc admission. Default=4
 num_hp
 Number of high pressure stages not including inlet stage
 num_ip
 Number of intermediate pressure stages
 num_lp
 Number of low pressure stages not including outlet stage
 hp_split_locations
 A list of index locations of splitters in the HP section. The indexes indicate after which stage to include splitters. 0 is between the inlet stage and the first regular HP stage.
 ip_split_locations
 A list of index locations of splitters in the IP section. The indexes indicate after which stage to include splitters.
 lp_split_locations
 A list of index locations of splitters in the LP section. The indexes indicate after which stage to include splitters.
 hp_disconnect
 HP Turbine stages to not connect to next with an arc. This is usually used to insert addtional units between stages on a flowsheet, such as a reheater
 ip_disconnect
 IP Turbine stages to not connect to next with an arc. This is usually used to insert addtional units between stages on a flowsheet, such as a reheater
 lp_disconnect
 LP Turbine stages to not connect to next with an arc. This is usually used to insert addtional units between stages on a flowsheet, such as a reheater
 hp_split_num_outlets
 Dict, hp split index: number of splitter outlets, if not 2
 ip_split_num_outlets
 Dict, ip split index: number of splitter outlets, if not 2
 lp_split_num_outlets
 Dict, lp split index: number of splitter outlets, if not 2
 initialize (dict) â€“ ProcessBlockData config for individual elements. Keys are BlockData indexes and values are dictionaries described under the â€śdefaultâ€ť argument above.
 idx_map (function) â€“ Function to take the index of a BlockData element and return the index in the initialize dict from which to read arguments. This can be provided to overide the default behavior of matching the BlockData index exactly to the index in initialize.
Returns: (TurbineMultistage) New instance
TurbineMultistageData ClassÂ¶

class
idaes.unit_models.power_generation.turbine_multistage.
TurbineMultistageData
(component)[source]Â¶ 
build
()[source]Â¶ General build method for UnitModelBlockData. This method calls a number of submethods which automate the construction of expected attributes of unit models.
Inheriting models should call super().build.
Parameters: None â€“ Returns: None

throttle_cv_fix
(value)[source]Â¶ Fix the thottle valve coefficients. These are generally the same for each of the parallel stages so this provides a convenient way to set them.
Parameters: value â€“ The value to fix the turbine inlet flow coefficients at

Steam/Water ValveÂ¶
This is a steam power generation turbine model for the stages between the inlet and outlet. This model inherits the PressureChanger model with the adiabatic options. Beyond the base pressure changer model this provides a pressure flow relation as a function of the valve opening fraction.
ExampleÂ¶
from pyomo.environ import ConcreteModel, SolverFactory, TransformationFactory
from idaes.core import FlowsheetBlock
from idaes.unit_models.power_generation import SteamValve
from idaes.property_models import iapws95
from idaes.ui.report import degrees_of_freedom, active_equalities
solver = SolverFactory('ipopt')
solver.options = {'tol': 1e6}
m = ConcreteModel()
m.fs = FlowsheetBlock(default={"dynamic": False})
m.fs.properties = iapws95.Iapws95ParameterBlock()
m.fs.valve = SteamValve(default={"property_package": m.fs.properties})
hin = iapws95.htpx(T=880, P=2.4233e7)
# set inlet
m.fs.valve.inlet.enth_mol[0].fix(hin)
m.fs.valve.inlet.flow_mol[0].fix(26000/4.0)
m.fs.valve.inlet.pressure[0].fix(2.5e7)
m.fs.valve.Cv.fix(0.01)
m.fs.valve.valve_opening.fix(0.5)
m.fs.valve.initialize(outlvl=1)
ParametersÂ¶
Expression  Symbol  Index Sets  Doc 

flow_scale 
\(s_f\)  None  Factor for scaling the pressureflow equation, should be same magnitude as expected flow rate 
VariablesÂ¶
This model adds a variable to account for mechanical efficiency to the base PressureChanger model.
Variable  Symbol  Index Sets  Doc 

Cv 
\(C_v\)  None  Valve coefficient for liquid [mol/s/Pa^0.5] for vapor [mol/s/Pa] 
valve_opening 
\(x\)  time  The fraction that the valve is open from 0 to 1 
ExpressionsÂ¶
Currently this model provides two additional expressions, with are not available in the pressure changer model.
Expression  Symbol  Index Sets  Doc 

valve_function 
\(f(x)\)  time  This is a valve function that describes how the fraction open affects flow. 
ConstraintsÂ¶
The pressure flow relation is added to the inherited constraints from the PressureChanger model.
If the phase
option is set to "Liq"
the following equation describes the pressureflow relation.
If the phase
option is set to "Vap"
the following equation describes the pressureflow relation.
InitializationÂ¶
This just calls the initialization routine from PressureChanger, but it is wrapped in a function to ensure the state after initialization is the same as before initialization. The arguments to the initialization method are the same as PressureChanger.
SteamValve ClassÂ¶

class
idaes.unit_models.power_generation.valve_steam.
SteamValve
(*args, **kwargs)Â¶ Basic steam valve models
Parameters:  rule (function) â€“ A rule function or None. Default rule calls build().
 concrete (bool) â€“ If True, make this a toplevel model. Default  False.
 ctype (str) â€“ Pyomo ctype of the block. Default  â€śBlockâ€ť
 default (dict) â€“
Default ProcessBlockData config
 Keys
 dynamic
 Indicates whether this model will be dynamic or not, default = useDefault. Valid values: { useDefault  get flag from parent (default = False), True  set as a dynamic model, False  set as a steadystate model.}
 has_holdup
 Indicates whether holdup terms should be constructed or not. Must be True if dynamic = True, default  False. Valid values: { True  construct holdup terms, False  do not construct holdup terms}
 material_balance_type
 Indicates what type of mass balance should be constructed, default  MaterialBalanceType.useDefault. Valid values: { MaterialBalanceType.useDefault  refer to property package for default balance type **MaterialBalanceType.none  exclude material balances, MaterialBalanceType.componentPhase  use phase component balances, MaterialBalanceType.componentTotal  use total component balances, MaterialBalanceType.elementTotal  use total element balances, MaterialBalanceType.total  use total material balance.}
 energy_balance_type
 Indicates what type of energy balance should be constructed, default  EnergyBalanceType.useDefault. Valid values: { EnergyBalanceType.useDefault  refer to property package for default balance type **EnergyBalanceType.none  exclude energy balances, EnergyBalanceType.enthalpyTotal  single enthalpy balance for material, EnergyBalanceType.enthalpyPhase  enthalpy balances for each phase, EnergyBalanceType.energyTotal  single energy balance for material, EnergyBalanceType.energyPhase  energy balances for each phase.}
 momentum_balance_type
 Indicates what type of momentum balance should be constructed, default  MomentumBalanceType.pressureTotal. Valid values: { MomentumBalanceType.none  exclude momentum balances, MomentumBalanceType.pressureTotal  single pressure balance for material, MomentumBalanceType.pressurePhase  pressure balances for each phase, MomentumBalanceType.momentumTotal  single momentum balance for material, MomentumBalanceType.momentumPhase  momentum balances for each phase.}
 has_phase_equilibrium
 Indicates whether terms for phase equilibrium should be constructed, default = False. Valid values: { True  include phase equilibrium terms False  exclude phase equilibrium terms.}
 compressor
 Indicates whether this unit should be considered a compressor (True (default), pressure increase) or an expander (False, pressure decrease).
 thermodynamic_assumption
 Flag to set the thermodynamic assumption to use for the unit.  ThermodynamicAssumption.isothermal (default)  ThermodynamicAssumption.isentropic  ThermodynamicAssumption.pump  ThermodynamicAssumption.adiabatic
 property_package
 Property parameter object used to define property calculations, default  useDefault. Valid values: { useDefault  use default package from parent model or flowsheet, PropertyParameterObject  a PropertyParameterBlock object.}
 property_package_args
 A ConfigBlock with arguments to be passed to a property block(s) and used when constructing these, default  None. Valid values: { see property package for documentation.}
 valve_function
 The type of valve function, if custom provide an expression rule with the valve_function_rule argument. default  ValveFunctionType.linear Valid values  { ValveFunctionType.linear, ValveFunctionType.quick_opening, ValveFunctionType.equal_percentage, ValveFunctionType.custom}
 valve_function_rule
 This is a rule that returns a time indexed valve function expression. This is required only if valve_function==ValveFunctionType.custom
 phase
 Expected phase of fluid in valve in {â€śLiqâ€ť, â€śVapâ€ť}
 initialize (dict) â€“ ProcessBlockData config for individual elements. Keys are BlockData indexes and values are dictionaries described under the â€śdefaultâ€ť argument above.
 idx_map (function) â€“ Function to take the index of a BlockData element and return the index in the initialize dict from which to read arguments. This can be provided to overide the default behavior of matching the BlockData index exactly to the index in initialize.
Returns: (SteamValve) New instance
SteamValveData ClassÂ¶

class
idaes.unit_models.power_generation.valve_steam.
SteamValveData
(component)[source]Â¶
Property Model LibraryÂ¶
Cubic Equations of StateÂ¶
This property package implements a general form of a cubic equation of state which can be used for most cubictype equations of state. This package supports phase equilibrium calculations with a smooth phase transition formulation that makes it amenable for equation oriented optimization. The following equations of state are currently supported:
 PengRobinson
 SoaveRedlichKwong
Flow basis: Molar
Units: SI units
State Variables:
The state block uses the following state variables:
 Total molar flow rate (mol/s) 
flow_mol
 Temperature (K) 
temperature
 Pressure (Pa) 
pressure
 Mole fraction of the mixture 
mole_frac_comp
InputsÂ¶
When instantiating the parameter block that uses this particular state block, 1 optional argument can be passed:
valid_phase
 "Liq" or "Vap" or ("Liq", "Vap") or ("Vap", "Liq")
The valid_phase
argument denotes the valid phases for a given set of inlet conditions. For example, if the user knows a priori that the it will only be a single phase (for example liquid only), then it is best not to include the complex flash equilibrium constraints in the model. If the user does not specify any option, then the package defaults to a 2 phase assumption meaning that the constraints to compute the phase equilibrium will be computed.
Degrees of FreedomÂ¶
In general, the general cubic equation of state has a number of degrees of freedom equal to 2 + the number of components in the system (total flow rate, temperature, pressure and N1 mole fractions). In some cases (primarily inlets to units), this is increased by 1 due to the removal of a constraint on the sum of mole fractions.
General Cubic Equation of StateÂ¶
All equations come from â€śThe Properties of Gases and Liquids, 4th Editionâ€ť by Reid, Prausnitz and Poling. The general cubic equation of state is represented by the following equations:
where \(Z\) is the compressibility factor of the mixture, \(a_m\) and \(b_m\) are properties of the mixture and \(u\) and \(w\) are parameters which depend on the specific equation of state being used as show in the table below.
Equation  \(u\)  \(w\)  \(Omega_A\)  \(Omega_B\)  \(kappa_j\) 

PengRobinson  2  1  0.45724  0.07780  \((1+(1T_r^2)(0.37464+1.54226\omega_j0.26992\omega_j^2))^2\) 
SoaveRedlichKwong  1  0  0.42748  0.08664  \((1+(1T_r^2)(0.48+1.574\omega_j0.176\omega_j^2))^2\) 
The properties \(a_m\) and \(b_m\) are calculated from component specific properties \(a_j\) and \(b_j\) as shown below:
where \(P_{c,j}\) and \(T_{c,j}\) are the component critical pressures and temperatures, \(y_j\) is the mole fraction of component :math`j`, \(k_{ij}\) are a set of binary interaction parameters which are specific to the equation of state and \(\Omega_A\), \(\Omega_B\) and \(\kappa_j\) are taken from the table above. \(\omega_j\) is the Pitzer acentric factor of each component.
The cubic equation of state is solved for each phase via a call to an external function which automatically identifies the correct root of the cubic and returns the value of \(Z\) as a function of \(A\) and \(B\) along with the first and second partial derivatives.
VLE Model with Smooth Phase TransitionÂ¶
The flash equations consists of the following equations:
At the equilibrium condition, the fugacity of the vapor and liquid phase are defined as follows:
The cubic equation of state is solved to find \(Z\) for each phase subject to the composition of that phase. Typically, the flash calculations are computed at a given temperature, \(T\). However, the flash calculations become trivial if the given conditions do not fall in the two phase region. For simulation only studies, the user may know a priori the condition of the stream but when the same set of equations are used for optimization, there is a high probability that the specifications can transcend the phase envelope and hence the flash equations included may be trivial in the single phase region (i.e. liquid or vapor only). To circumvent this problem, property packages in IDAES that support VLE will compute the flash calculations at an â€śequilibriumâ€ť temperature \(T_{eq}\). The equilibrium temperature is computed as follows:
where \(T_{eq}\) is the equilibrium temperature at which flash calculations are computed, \(T\) is the stream temperature, \(T_{1}\) is the intermediate temperature variable, \(T_{bubble}\) is the bubble point temperature of mixture, and \(T_{dew}\) is the dew point temperature of the mixture. Note that, in the above equations, approximations are used for the max and min functions as follows:
where \(\epsilon_1\) and \(\epsilon_2\) are smoothing parameters (mutable). The default values are 0.01 and 0.0005 respectively. It is recommended that \(\epsilon_1\) > \(\epsilon_2\). Please refer to reference 4 for more details. Therefore, it can be seen that if the stream temperature is less than that of the bubble point temperature, the VLE calculations will be computed at the bubble point. Similarly, if the stream temperature is greater than the dew point temperature, then the VLE calculations are computed at the dew point temperature. For all other conditions, the equilibrium calculations will be computed at the actual temperature.
Other ConstraintsÂ¶
Additional constraints are included in the model to compute the thermodynamic properties based on the cubic equation of state, such as enthalpies and entropies. Please note that, these constraints are added only if the variable is called for when building the model. This eliminates adding unnecessary constraints to compute properties that are not needed in the model.
All thermophysical properties are calculated using an ideal and residual term, such that:
The residual term is derived from the partial derivatives of the cubic equation of state, whilst the ideal term is determined using empirical correlations.
EnthalpyÂ¶
The ideal enthalpy term is given by:
The residual enthalpy term is given by:
EntropyÂ¶
The ideal entropy term is given by:
The residual entropy term is given by:
FugacityÂ¶
Fugacity is calculated from the system pressure, mole fractions and fugacity coefficients as follows:
Fugacity CoefficientÂ¶
The fugacity coefficient is calculated from the departure function of the cubic equation of state as shown below:
Gibbs EnergyÂ¶
The Gibbs energy of the system is calculated using the definition of Gibbs energy:
List of VariablesÂ¶
Variable Name  Description  Units 

flow_mol 
Total molar flow rate  mol/s 
mole_frac_comp 
Mixture mole fraction indexed by component  None 
temperature 
Temperature  K 
pressure 
Pressure  Pa 
flow_mol_phase 
Molar flow rate indexed by phase  mol/s 
mole_frac_phase_comp 
Mole fraction indexed by phase and component  None 
pressure_sat 
Saturation or vapor pressure indexed by component  Pa 
dens_mol_phase 
Molar density indexed by phase  mol/m3 
dens_mass_phase 
Mass density indexed by phase  kg/m3 
enth_mol_phase 
Molar enthalpy indexed by phase  J/mol 
enth_mol 
Molar enthalpy of mixture  J/mol 
entr_mol_phase 
Molar entropy indexed by phase  J/mol.K 
entr_mol 
Molar entropy of mixture  J/mol.K 
fug_phase_comp 
Fugacity indexed by phase and component  Pa 
fug_coeff_phase_comp 
Fugacity coefficient indexed by phase and component  None 
gibbs_mol_phase 
Molar Gibbs energy indexed by phase  J/mol 
mw 
Molecular weight of mixture  kg/mol 
mw_phase 
Molecular weight by phase  kg/mol 
temperature_bubble 
Bubble point temperature  K 
temperature_dew 
Dew point temperature  K 
pressure_bubble 
Bubble point pressure  Pa 
pressure_dew 
Dew point pressure  Pa 
_teq 
Temperature at which the VLE is calculated  K 
List of ParametersÂ¶
Parameter Name  Description  Units 

cubic_type 
Type of cubic equation of state to use, from CubicEoS Enum  None 
pressure_ref 
Reference pressure  Pa 
temperature_ref 
Reference temperature  K 
omega 
Pitzer acentricity factor  None 
kappa 
Binary interaction parameters for EoS (note that parameters are specific for a given EoS  None 
mw_comp 
Component molecular weights  kg/mol 
cp_ig 
Parameters for calculating component heat capacities  varies 
dh_form 
Component standard heats of formation (used for enthalpy at reference state)  J/mol 
ds_form 
Component standard entropies of formation (used for entropy at reference state)  J/mol.K 
antoine 
Component Antoine coefficients (used to initialize bubble and dew point calculations)  bar, K 
Config Block DocumentationÂ¶

class
idaes.property_models.cubic_eos.cubic_prop_pack.
CubicParameterData
(component)[source]Â¶ General Property Parameter Block Class

class
idaes.property_models.cubic_eos.cubic_prop_pack.
CubicStateBlock
(*args, **kwargs)Â¶ Parameters:  rule (function) â€“ A rule function or None. Default rule calls build().
 concrete (bool) â€“ If True, make this a toplevel model. Default  False.
 ctype (str) â€“ Pyomo ctype of the block. Default  â€śBlockâ€ť
 default (dict) â€“
Default ProcessBlockData config
 Keys
 parameters
 A reference to an instance of the Property Parameter Block associated with this property package.
 defined_state
 Flag indicating whether the state should be considered fully defined, and thus whether constraints such as sum of mass/mole fractions should be included, default  False. Valid values: { True  state variables will be fully defined, False  state variables will not be fully defined.}
 has_phase_equilibrium
 Flag indicating whether phase equilibrium constraints should be constructed in this state block, default  True. Valid values: { True  StateBlock should calculate phase equilibrium, False  StateBlock should not calculate phase equilibrium.}
 initialize (dict) â€“ ProcessBlockData config for individual elements. Keys are BlockData indexes and values are dictionaries described under the â€śdefaultâ€ť argument above.
 idx_map (function) â€“ Function to take the index of a BlockData element and return the index in the initialize dict from which to read arguments. This can be provided to overide the default behavior of matching the BlockData index exactly to the index in initialize.
Returns: (CubicStateBlock) New instance
VaporLiquid Equilibrium Property Models (Ideal Gas  Nonideal Liquids)Â¶
This property package supports phase equilibrium calucations with a smooth phase transition formulation that makes it amenable for equation oriented optimization. The gas phase is assumed to be ideal and for the liquid phase, the package supports an ideal liquid or a nonideal liquid using an activity coefficient model. To compute the activity coefficient, the package currently supports the Non Random Two Liquid Model (NRTL) or the Wilson model. Therefore, this property package supports the following combinations for gasliquid mixtures for VLE calculations:
 Ideal (vapor)  Ideal (liquid)
 Ideal (vapor)  NRTL (liquid)
 Ideal (vapor)  Wilson (liquid)
Flow basis: Molar
Units: SI units
State Variables:
The state block supports the following two sets of state variables:
Option 1  â€śFTPzâ€ť:
 Total molar flow rate (mol/s) 
flow_mol
 Temperature (K) 
temperature
 Presure (Pa) 
pressure
 Mole fraction of the mixture 
mole_frac_comp
Option 2  â€śFcTPâ€ť:
 Component molar flow rate (mol/s) 
flow_mol_comp
 Temperature (K) 
temperature
 Presure (Pa) 
pressure
The user can specify the choice of state variables while instantiating the parameter block. See the Inputs section for more details.
Support for other combinations of state variables will be made available in the future.
InputsÂ¶
When instantiating the parameter block that uses this particular state block, 2 arguments can be passed:
valid_phase
 "Liq" or "Vap" or ("Liq", "Vap") or ("Vap", "Liq")activity_coeff_model
 "Ideal" or "NRTL" or "Wilson"state_vars
 "FTPz" or "FcTP"
The valid_phase
argument denotes the valid phases for a given set of inlet conditions. For example, if the user knows a priori that the it will only be a single phase (for example liquid only), then it is best not to include the complex flash equilibrium constraints in the model. If the user does not specify any option, then the package defaults to a 2 phase assumption meaning that the constraints to compute the phase equilibrium will be computed.
The activity_coeff_model
denotes the liquid phase assumption to be used. If the user does not specify any option, then the package defaults to asuming an ideal liquid assumption.
The state_vars
denotes the preferred set of state variables to be used. If the user does not specify any option, then the package defaults to using the total flow, mixture mole fraction, temperature and pressure as the state variables.
Degrees of FreedomÂ¶
The number of degrees of freedom that need to be fixed to yield a square problem (i.e. degrees of freedom = 0) depends on the options selected. The following table provides a summary of the variables to be fixed and also the corresponding variable names in the model.
Property Model Type  State variables  Additional Variables  Total number of variables 

Ideal (vapor)  Ideal (liquid)  flow_mol , temperature , pressure , mole_frac_comp 
None  3 + \(N_{c}\) 
Ideal (vapor)  NRTL (liquid)  flow_mol , temperature , pressure , mole_frac_comp 
alpha , tau 
3 + \(N_{c}\) + \(2N_{c}^{2}\) 
Ideal (vapor)  Wilson (liquid)  flow_mol , temperature , pressure , ``mole_frac`_comp` 
vol_mol_comp , tau 
3 + \(N_{c}\) + \(2N_{c}^{2}\) 
Please refer to reference 3 for recommended values for tau
.
VLE Model with Smooth Phase TransitionÂ¶
The flash equations consists of the following equations depending on the choice of state variables selected by the user.
If the state variables are total flow, mole fraction, temperature, and pressure, then the following constraints are implemented:
If the state variables are component flow rates, temperature, and pressure, then the following constraints are implemented:
The equilibrium condition, the fugacity of the vapor and liquid phase are defined as follows:
The equilibrium constraint is written as a generic constraint such that it can be extended easily for nonideal gases and liquids. As this property package only supports an ideal gas, the fugacity coefficient (\(\phi_{i}\)) for the vapor phase is 1 and hence the expression reduces to \(y_{i}P\). For the liquid phase, if the ideal option is selected then the activity coefficient (\(\nu_{i}\)) is 1. If an activity coefficient model is selected then corresponding constraints are added to compute the activity coefficient.
Typically, the flash calculations are computed at a given temperature, \(T\). However, the flash calculations become trivial if the given conditions do not fall in the two phase region. For simulation only studies, the user may know a priori the condition of the stream but when the same set of equations are used for optimization, there is a high probablity that the specifications can transcend the phase envelope and hence the flash equations included may be trivial in the single phase region (i.e. liquid or vapor only). To circumvent this problem, property packages in IDAES that support VLE will compute the flash calculations at an â€śequilibriumâ€ť temperature \(T_{eq}\). The equilibrium temperature is computed as follows:
where \(T_{eq}\) is the equilibrium temperature at which flash calculations are computed, \(T\) is the stream temperature, \(T_{1}\) is the intermediate temperature variable, \(T_{bubble}\) is the bubble point temperature of mixture, and \(T_{dew}\) is the dew point temperature of the mixture. Note that, in the above equations, approximations are used for the max and min functions as follows:
where \(\epsilon_1\) and \(\epsilon_2\) are smoothing parameters(mutable). The default values are 0.01 and 0.0005 respectively. It is recommended that \(\epsilon_1\) > \(\epsilon_2\). Please refer to reference 4 for more details. Therefore, it can be seen that if the stream temperature is less than that of the bubble point temperature, the VLE calucalations will be computed at the bubble point. Similarly, if the stream temperature is greater than the dew point temperature, then the VLE calculations are computed at the dew point temperature. For all other conditions, the equilibrium calcualtions will be computed at the actual temperature.
Additional constraints are included in the model to compute the thermodynamic properties such as component saturation pressure, enthalpy, specific heat capacity. Please note that, these constraints are added only if the variable is called for when building the model. This eliminates adding unnecessary constraints to compute properties that are not needed in the model.
The saturation or vapor pressure (pressure_sat
) for component \(i\) is computed using the following correlation[1]:
where \(P_c\) is the critical pressure, \(T_c\) is the critical temperature of the component and \(T_{eq}\) is the equilibrium temperature at which the saturation pressure is computed. Please note that when using this expression, \(T_{eq}<T_{c}\) is required and when violated it results in a negative number raised to the power of a fraction.
The specific enthalpy (enthalpy_comp_liq
) for component \(i\) is computed using the following expression for the liquid phase:
The specific enthalpy (enthalpy_comp_vap
) for component \(i\) is computed using the following expression for the vapor phase:
The mixture specific enthapies (enthalpy_liq
& enthalpy_vap
) are computed using the following expressions for the liquid and vapor phase respectively:
Similarly, specific entropies are calcuated as follows. The specific entropy (entropy_comp_liq
) for component \(i\) is computed using the following expression for the liquid phase:
The specific entropy (entropy_comp_vap
) for component \(i\) is computed using the following expression for the vapor phase:
Please refer to references 1 and 2 to get parameters for different components.
Activity Coefficient Model  NRTLÂ¶
The activity coefficient for component \(i\) is computed using the following equations when using the NonRandom Two Liquid model [3]:
where \(\alpha_{ij}\) is the nonrandomness parameter and \(\tau_{ij}\) is the binary interaction parameter for the NRTL model. Note that in the IDAES implementation, these are declared as variables that allows for more flexibility and the ability to use these in a parameter estimation problem. These NRTL model specific variables need to be either fixed for a given component set or need to be estimated from VLE data.
The bubble point is computed by enforcing the following condition:
Activity Coefficient Model  WilsonÂ¶
The activity coefficient for component \(i\) is computed using the following equations when using the Wilson model [3]:
where \(v_{i}\) is the molar volume of component \(i\) and \(\tau_{ij}\) is the binary interaction parameter. These are Wilson model specific variables that either need to be fixed for a given component set or need to be estimated from VLE data.
The bubble point is computed by enforcing the following condition:
List of VariablesÂ¶
Variable Name  Description  Units 

flow_mol 
Total molar flow rate  mol/s 
mole_frac_comp 
Mixture mole fraction indexed by component  None 
temperature 
Temperature  K 
pressure 
Pressure  Pa 
flow_mol_phase 
Molar flow rate indexed by phase  mol/s 
mole_frac_phase_comp 
Mole fraction indexed by phase and component  None 
pressure_sat 
Saturation or vapor pressure indexed by component  Pa 
density_mol_phase 
Molar density indexed by phase  mol/m3 
ds_vap 
Molar entropy of vaporization  J/mol.K 
enthalpy_comp_liq 
Liquid molar enthalpy indexed by component  J/mol 
enthalpy_comp_vap 
Vapor molar enthalpy indexed by component  J/mol 
enthalpy_liq 
Liquid phase enthalpy  J/mol 
enthalpy_vap 
Vapor phase enthalpy  J/mol 
entropy_comp_liq 
Liquid molar entropy indexed by component  J/mol 
entropy_comp_vap 
Vapor molar entropy indexed by component  J/mol 
entrolpy_liq 
Liquid phase entropy  J/mol 
entropy_vap 
Vapor phase entropy  J/mol 
temperature_bubble 
Bubble point temperature  K 
temperature_dew 
Dew point temperature  K 
_temperature_equilibrium 
Temperature at which the VLE is calculated  K 
Variable Name  Description  Units 

alpha 
Nonrandomness parameter indexed by component and component  None 
tau 
Binary interaction parameter indexed by component and component  None 
activity_coeff_comp 
Activity coefficient indexed by component  None 
Variable Name  Description  Units 

vol_mol_comp 
Molar volume of component indexed by component  None 
tau 
Binary interaction parameter indexed by component and component  None 
activity_coeff_comp 
Activity coefficient indexed by component  None 
InitializationÂ¶
Config Block DocumentationÂ¶

class
idaes.property_models.activity_coeff_models.activity_coeff_prop_pack.
ActivityCoeffParameterBlock
(*args, **kwargs)Â¶ Parameters:  rule (function) â€“ A rule function or None. Default rule calls build().
 concrete (bool) â€“ If True, make this a toplevel model. Default  False.
 ctype (str) â€“ Pyomo ctype of the block. Default  â€śBlockâ€ť
 default (dict) â€“
Default ProcessBlockData config
 Keys
 default_arguments
 Default arguments to use with Property Package
 activity_coeff_model
 Flag indicating the activity coefficient model to be used for the nonideal liquid, and thus corresponding constraints should be included, default  Ideal liquid. Valid values: { â€śNRTLâ€ť  Non Random Two Liquid Model, â€śWilsonâ€ť  Wilson Liquid Model,}
 state_vars
 Flag indicating the choice for state variables to be used for the state block, and thus corresponding constraints should be included, default  FTPz Valid values: { â€śFTPxâ€ť  Total flow, Temperature, Pressure and Mole fraction, â€śFcTPâ€ť  Component flow, Temperature and Pressure}
 valid_phase
 Flag indicating the valid phase for a given set of conditions, and thus corresponding constraints should be included, default  (â€śVapâ€ť, â€śLiqâ€ť). Valid values: { â€śLiqâ€ť  Liquid only, â€śVapâ€ť  Vapor only, (â€śVapâ€ť, â€śLiqâ€ť)  Vaporliquid equilibrium, (â€śLiqâ€ť, â€śVapâ€ť)  Vaporliquid equilibrium,}
 initialize (dict) â€“ ProcessBlockData config for individual elements. Keys are BlockData indexes and values are dictionaries described under the â€śdefaultâ€ť argument above.
 idx_map (function) â€“ Function to take the index of a BlockData element and return the index in the initialize dict from which to read arguments. This can be provided to overide the default behavior of matching the BlockData index exactly to the index in initialize.
Returns: (ActivityCoeffParameterBlock) New instance

class
idaes.property_models.activity_coeff_models.activity_coeff_prop_pack.
ActivityCoeffStateBlock
(*args, **kwargs)Â¶ Parameters:  rule (function) â€“ A rule function or None. Default rule calls build().
 concrete (bool) â€“ If True, make this a toplevel model. Default  False.
 ctype (str) â€“ Pyomo ctype of the block. Default  â€śBlockâ€ť
 default (dict) â€“
Default ProcessBlockData config
 Keys
 parameters
 A reference to an instance of the Property Parameter Block associated with this property package.
 defined_state
 Flag indicating whether the state should be considered fully defined, and thus whether constraints such as sum of mass/mole fractions should be included, default  False. Valid values: { True  state variables will be fully defined, False  state variables will not be fully defined.}
 has_phase_equilibrium
 Flag indicating whether phase equilibrium constraints should be constructed in this state block, default  True. Valid values: { True  StateBlock should calculate phase equilibrium, False  StateBlock should not calculate phase equilibrium.}
 initialize (dict) â€“ ProcessBlockData config for individual elements. Keys are BlockData indexes and values are dictionaries described under the â€śdefaultâ€ť argument above.
 idx_map (function) â€“ Function to take the index of a BlockData element and return the index in the initialize dict from which to read arguments. This can be provided to overide the default behavior of matching the BlockData index exactly to the index in initialize.
Returns: (ActivityCoeffStateBlock) New instance
ReferencesÂ¶
 â€śThe properties of gases and liquids by Robert C. Reidâ€ť
 â€śPerryâ€™s Chemical Engineers Handbook by Robert H. Perryâ€ť.
 H. Renon and J.M. Prausnitz, â€śLocal compositions in thermodynamic excess functions for liquid mixtures.â€ť, AIChE Journal Vol. 14, No.1, 1968.
 AP Burgard, JP Eason, JC Eslick, JH Ghouse, A Lee, LT Biegler, DC Miller. â€śA Smooth, Square Flash Formulation for Equation Oriented Flowsheet Optimizationâ€ť, Computer Aided Chemical Engineering 44, 871876, 2018
Water/Steam  IAPWS95Â¶
Accurate and thermodynamically consistent steam properties are provided for the IDAES framework by implementing the International Association for the Properties of Water and Steamâ€™s â€śRevised Release on the IAPWS Formulation 1995 for the Thermodynamic Properties of Ordinary Water Substance for General and Scientific Use.â€ť Nonanalytic terms designed to improve accuracy very near the critical point were omitted, because they cause a singularity at the critical point, a feature which is undesirable in optimization problems. The IDAES implementation provides features which make the water and steam property calculations amenable to rigorous mathematical optimization.
ExampleÂ¶
Theses modules can be imported as:
from idaes.property_models import iapws95
The Heater unit model example, provides a simple example for using water properties.
import pyomo.environ as pe # Pyomo environment
from idaes.core import FlowsheetBlock, MaterialBalanceType
from idaes.unit_models import Heater
from idaes.property_models import iapws95
# Create an empty flowsheet and steam property parameter block.
model = pe.ConcreteModel()
model.fs = FlowsheetBlock(default={"dynamic": False})
model.fs.properties = iapws95.Iapws95ParameterBlock(default={
"phase_presentation":iapws95.PhaseType.LG,
"state_vars":iapws95.StateVars.PH})
# Add a Heater model to the flowsheet.
model.fs.heater = Heater(default={
"property_package": model.fs.properties,
"material_balance_type": MaterialBalanceType.componentTotal})
# Setup the heater model by fixing the inputs and heat duty
model.fs.heater.inlet[:].enth_mol.fix(4000)
model.fs.heater.inlet[:].flow_mol.fix(100)
model.fs.heater.inlet[:].pressure.fix(101325)
model.fs.heater.heat_duty[:].fix(100*20000)
# Initialize the model.
model.fs.heater.initialize()
Since all properties except the state variables are Pyomo Expressions in the water properties module, after solving the problem any property can be calculated in any state block. Continuing from the heater example, to get the viscosity of both phases, the lines below could be added.
mu_l = pe.value(model.fs.heater.control_volume.properties_out[0].visc_d_phase["Liq"])
mu_v = pe.value(model.fs.heater.control_volume.properties_out[0].visc_d_phase["Vap"])
For more information about how StateBlocks and PropertyParameterBlocks work see the StateBlock documentation.
UnitsÂ¶
The iapws95 property module uses SI units (m, kg, s, J, mol) for all public variables and expressions. Temperature is in K. Note that this means molecular weight is in the unusual unit of kg/mol.
A few expressions intended to be used internally and all external function calls use units of kg, kJ, kPa, and K. These generally are not needed by the end user.
MethodsÂ¶
These methods use the IAPWS95 formulation for scientific use for thermodynamic properties (Wagner and Pruss, 2002; IAPWS, 2016). To solve the phase equilibrium, the method of Akasaka (2008) was used. For solving these equations, some relations from the IAPWS97 formulation for industrial use are used as initial values (Wagner et al., 2002). The industrial formulation is slightly discontinuous between different regions, so it may not be suitable for optimization. In addition to thermodynamic quantities, viscosity and thermal conductivity are calculated (IAPWS, 2008; IAPWS, 2011).
External FunctionsÂ¶
The IAPWS95 formulation uses density and temperature as state variables. For most applications those state variables are not the most convenient choices. Using other state variables requires solving equations to get density and temperature from the chosen state variables. These equations can have numerous solutions only one of which is physically meaningful. Rather than solve these equations as part of the full process simulation, external functions were developed that can solve the equations required to change state variables and guarantee the correct roots.
The external property functions are written in C++ and complied such that they can be called by AMPL solvers. See the Installation page for information about compiling these functions. The external functions provide both first and second derivatives for all property function calls, however at phase transitions some of these functions may be nonsmooth.
IDAES Framework WrapperÂ¶
A wrapper for the external functions is provided for compatibility with the IDAES framework. Most properties are available as Pyomo Expressions from the wrapper. Only the state variables are model variables. Benefits of using mostly expressions in the property package are: no initialization is required specifically for the property package, the model has fewer equations, and all properties can be easily calculated after the model is solved from the state variable values even if they were not used in the model. Calls to the external functions are used within expressions so users do not need to directly call any functions. The potential downside of the extensive use of expressions here is that combining the expressions to form constraints could yield equations that are more difficult to solve than, they would have been if an equivalent system of equations was written with more variables and simpler equations. Quantifying the effect of writing larger equations with fewer variables is difficult. Experience suggests in this particular case more expressions and fewer variables is better.
Although not generally used, the wrapper provides direct access to the ExternalFunctions, including intermediate functions. For more information see section ExternalFunctions. These are mostly available for testing purposes.
Phase PresentationÂ¶
The property package wrapper can present fluid phase information to the
IDAES framework in different ways. See the
class reference for details
on how to set these options. The phase_presentation=PhaseType.MIX
option
looks like one phase called â€śMixâ€ť to the IDAES framework. The property
package will calculate a phase fraction. This will bypass any two phase
handling equations written for unit models, and should work with any unit model
options as long as you do not want to separate the phases. The benefit of this
option is that it can potentially lead to a simpler set of equations.
The phase_presentation=PhaseType.LG
option appears to the IDAES framework to
be two phases â€śVapâ€ť and â€śLiqâ€ť. This option requires one of two unit model
options to be set. You can use the total material balance option for unit
models, to specify that only one material balance equation should be written
not one per phase. The other possible option is to specify
has_phase_equlibrium=True
. This will still write a material balance
per phase, but will add a phase generation term to the model. For the IAPWS95
package, it is generally recommended that specifying total material balances is
best because it results in a problem with fewer variables.
There are also two single phase options phase_presentation=PhaseType.L
and
phase_presentation=PhaseType.G
, these present a single phase â€śLiqâ€ť or â€śVapâ€ť
to the framework. The vapor fraction will also always return 0 or 1 as
appropriate. These options can be used when the phase of a fluid is know for
certain to only be liquid or only be vapor. For the temperaturepressurevapor
fraction formulation, this eliminates the complementarity constraint, but for the
enthalpypressure formulation, where the vapor fraction is always calculated,
the single phase options probably do not provide any real benefit.
PressureEnthalpy FormulationÂ¶
The advantage of this choice of state variables is that it is very robust when phase changes occur, and is especially useful when it is not known if a phase change will occur. The disadvantage of this choice of state variables is that for equations like heat transfer equations that are highly dependent on temperature, a model could be harder to solve near regions with phase change. Temperature is a nonsmooth function with nonsmoothness when transitioning from the singlephase to the twophase region. Temperature also has a zero derivative with respect to enthalpy in the twophase region, so near the twophase region solving a constraint that specifies a specific temperature may not be possible.
The variables for this form are flow_mol
(mol/s), pressure
(Pa), and
enth_mol
(J/mol).
Since temperature and vapor fraction are not state variables in this formulation, they are provided by expressions, and cannot be fixed. For example, to set a temperature to a specific value, a constraint could be added which says the temperature expression equals a fixed value.
These expressions are specific to the PH formulation:
temperature
 Expression that calculates temperature by calling an ExternalFunction of enthalpy and pressure. This expression is nonsmooth in the transition from singlephase to twophase and has a zero derivative with respect to enthalpy in the twophase region.
vapor_frac
 Expression that calculates vapor fraction by calling an ExternalFunction of enthalpy and pressure. This expression is nonsmooth in the transition from singlephase to twophase and has a zero derivative with respect to enthalpy in the singlephase region, where the value is 0 (liquid) or 1 (vapor).
TemperaturePressureVapor FractionÂ¶
This formulation uses temperature (K), pressure (Pa), and vapor fraction as state variables. When a single phase option is given, the vapor fraction is fixed to the appropriate value and not included in the state variable set. For single phase, the complementarity constraint is also deactivated.
A complementarity constraint is required for the TPx formulation. First, two expressions are defined below where \(P^\) is pressure under saturation pressure and \(P^+\) is pressure over saturation pressure. The max function is provided by an IDAES utility function which provides a smooth max expression.
With the pressure over and pressure under saturated pressure expressions a complementarity constraint can be written. If the pressure under saturation is more than zero, only vapor exists. If the pressure over saturation is greater than zero only a liquid exists. If both are about zero two phases can exist. The saturation pressure function maxes out at the critical pressure and any temperature above the critical temperature will yield a saturation pressure that is the critical pressure, so supercritical fluids will be classified as liquids as the convention for this property package.
Assuming the vapor fraction (\(x\)) is positive and noting that only one of \(P^+\) and \(P^\) can be nonzero (approximately), the complementarity equation above requires \(x\) to be 0 when \(P^+\) is not zero (liquid) or \(x\) to be 1 when \(P^\) is not zero (vapor). When both \(P^+\) and \(P^\) are about 0, the complementarity constraint says nothing about x, but it does provide another constraint, that \(P=P_{\text{sat}}\). When two phases are present \(x\) can be found by the unit model energy balance and the temperature will be \(T_{\text{sat}}\).
An alternative approach is sometimes useful. If you know for certain that you have two phases, the complementarity constraint can be deactivated and a \(P=P_{\text{sat}}\) or \(T=T_{\text{sat}}\) constraint can be added.
Using the TPx formulation requires better initial guesses than the PH form. It is not strictly necessary but it is best to try to get an initial guess that is in the correct phase region for the expected result model.
ExpressionsÂ¶
Unless otherwise noted, the property expressions are common to both the
TPx and PH formulations. For phase specific properties, valid phase indexes
are "Liq"
and "Vap"
Expression  Description 

mw 
Molecular weight (kg/mol) 
tau 
Critical temperature divided by temperature (unitless) 
temperature 
Temperature (K) if PH form 
temperature_red 
Reduced temperature, temperature divided by critical temperature (unitless) 
temperature_sat 
Saturation temperature (K) 
tau_sat 
Critical temperature divided by saturation temperature (unitless) 
pressure_sat 
Saturation pressure (Pa) 
dens_mas 