Modular Property Package Framework#
Contents#
Introduction#
Note
The modular property package framework is still under development. Whilst the current framework is functional, features are still being developed and added.
The modular property package framework builds upon the existing framework for implementing property packages within IDAES, and will not prevent the use of custom written property packages in the future. Due to the complex nature of thermophysical property calculations, the modular property framework cannot support all possible materials and applications. Whilst it is hoped that the modular framework will be able to handle most common applications, users with more unusual systems or those solving computationally intensive problems may need to write custom property packages for their cases.
Property packages represent the core of any process model, and having a suitable property package is key to successfully modeling any process system. However, developing property packages is a significant challenge even for experienced modelers as they involve large numbers of tightly coupled constraints and parameters. The goal of the IDAES Modular Property Package Framework is to provide a flexible platform on which users can build property packages for common types of systems by calling upon libraries of modular sub-models to build up complex property calculations with the least effort possible.
The Modular Property Package Framework breaks down property packages into a number of components which can be assembled in a modular fashion. Users need only provide those components which they require for their system of interest, and components can be drawn from libraries of existing components or provided by the user as custom code. Details on how to set up the definition of a property package using the modular framework are given here.
The components which make up a modular property package are as follows:
Choose a base set of units of measurement for the property package.
Define the components which make up the material of interest, including methods for calculating the pure component properties of interest in the system.
Define the phases of interest for the application, including equations of state and other phase specific decisions.
Choose the set of state variables you wish to use and a reference state for the system.
(Optional) Define any phase equilibria which occurs in the system and methods associated with calculating this.
(Optional) A number of global options are available for further customizing behavior of certain property calculations.
(Optional) Define desired transport properties for phases as necessary.
The following sections will describe how to define a property package using the Modular Property Package Framework along with the libraries of sub-models currently available. Finally, the developers section describes how to go about defining your own custom components to use when creating custom property packages.
Note
Within most IDAES models “parameters” are in fact defined as Pyomo ‘Vars’ (i.e. variables) which are fixed at their defined values. Whilst Params would seem to be the logical choice for these, parameter estimation problems require the parameters being estimated to be defined as Vars so that the solver is free to vary them.
Initialization#
- class idaes.models.properties.modular_properties.base.generic_property.ModularPropertiesInitializer(**kwargs)[source]#
General Initializer for modular property packages.
This Initializer uses a hierarchical routine to initialize the property package using the following steps:
Initialize bubble and dew point calculations (if present)
Estimate vapor-liquid equilibrium T_eq (if present)
Solve for phase-equilibrium conditions
Initialize all remaining properties
The Pyomo solve_strongly_connected_components method is used at each step to converge the problem.
Note that for systems without vapor-liquid equilibrium the generic BlockTriangularizationInitializer is probably sufficient for initializing the property package.
- constraint_tolerance
Tolerance for checking constraint convergence
- output_level
Set output level for logging messages
- solver
Solver to use for initialization
- solver_options
Dict of options to pass to solver
- calculate_variable_options
Dict of options to pass to calc_var_kwds argument in solve_strongly_connected_components method. NOTE: models involving ExternalFunctions must set ‘diff_mode=differentiate.Modes.reverse_numeric’