\n",
@@ -67,19 +67,19 @@
"\n",
"## What Properties do I Need?\n",
"\n",
- "An important aspect of the IDAES Core Modeling Framework is that a modeler only needs to provide calculations for those properties that they will use within their process. Put another way, modelers do not need to include calculations for a property that they are not going to use in their model \u2013 this allows modelers to avoid introducing unnecessary complexity into their models to calculate a property they do not actually need. When combined with flexibility elsewhere in the modeling framework to control which equations are written in the unit models, this can even allow users to avoid calculating properties that would normally be considered mandatory \u2013 for example, a property package for a conceptual design flowsheet which does not include energy or momentum balances would not need to define specific enthalpy or even temperature and pressure as these will not be required by the unit models.\n",
+ "An important aspect of the IDAES Core Modeling Framework is that a modeler only needs to provide calculations for those properties that they will use within their process. Put another way, modelers do not need to include calculations for a property that they are not going to use in their model – this allows modelers to avoid introducing unnecessary complexity into their models to calculate a property they do not actually need. When combined with flexibility elsewhere in the modeling framework to control which equations are written in the unit models, this can even allow users to avoid calculating properties that would normally be considered mandatory – for example, a property package for a conceptual design flowsheet which does not include energy or momentum balances would not need to define specific enthalpy or even temperature and pressure as these will not be required by the unit models.\n",
"\n",
"This then raises the question of how do you know what properties you will need, especially if you are using models from a library you did not write yourself. To answer this, you should refer to the model documentation, and you can also use the [IDAES Properties Interrogator tool](https://idaes-pse.readthedocs.io/en/stable/reference_guides/model_libraries/generic/property_models/interrogator.html) to analyze your flowsheet and determine what properties are required.\n",
"\n",
"## Thermophysical Properties and Reaction Properties\n",
"\n",
- "Within the IDAES Core Modeling Framework, properties are divided into two classifications; thermophysical properties and reaction properties. Reaction properties are those properties related to chemical reactions (both equilibrium and rate-based, but not phase equilibrium) that occur within the system , whilst thermophysical properties include those properties related to thermodynamic relationships (including phase equilibrium) and transport properties. The reason for this separation is that thermophysical properties are required by all unit operations in a process (and need to be consistent with each other), whilst reaction properties are generally only required in specific unit operations identified as \u201creactors\u201d (and each reactor may have a different set of chemical reactions occurring in it). Thus, reaction properties are separated from the thermophysical property calculations to allow for modular implementation in only specific reactor units. This tutorial only deals with thermophysical properties, and reaction properties will be dealt with in a later tutorial.\n",
+ "Within the IDAES Core Modeling Framework, properties are divided into two classifications; thermophysical properties and reaction properties. Reaction properties are those properties related to chemical reactions (both equilibrium and rate-based, but not phase equilibrium) that occur within the system , whilst thermophysical properties include those properties related to thermodynamic relationships (including phase equilibrium) and transport properties. The reason for this separation is that thermophysical properties are required by all unit operations in a process (and need to be consistent with each other), whilst reaction properties are generally only required in specific unit operations identified as “reactors” (and each reactor may have a different set of chemical reactions occurring in it). Thus, reaction properties are separated from the thermophysical property calculations to allow for modular implementation in only specific reactor units. This tutorial only deals with thermophysical properties, and reaction properties will be dealt with in a later tutorial.\n",
"\n",
- "## What is a Property \u201cPackage\u201d?\n",
+ "## What is a Property “Package”?\n",
"\n",
- "Generally, properties (both thermophysical and reaction) are calculated using correlations that depend on some set of parameters (be they physical constants or empirical parameters). These parameters are constant across all instances of a property calculation in a flowsheet (i.e. each StateBlock uses the same parameters), it makes sense to store these parameters in a single, central location that all StateBlocks can refer to as necessary. Thus, the IDAES modeling framework has \u201cParameter Blocks\u201d which are attached to the flowsheet to contain all the global parameters associated with a given set of property calculations.\n",
+ "Generally, properties (both thermophysical and reaction) are calculated using correlations that depend on some set of parameters (be they physical constants or empirical parameters). These parameters are constant across all instances of a property calculation in a flowsheet (i.e. each StateBlock uses the same parameters), it makes sense to store these parameters in a single, central location that all StateBlocks can refer to as necessary. Thus, the IDAES modeling framework has “Parameter Blocks” which are attached to the flowsheet to contain all the global parameters associated with a given set of property calculations.\n",
"\n",
- "Thus, the calculations of thermophysical properties within the IDAES modeling framework is achieved using a \u201cpackage\u201d of three related modeling components (or classes); the Physical Parameter Block, the State Block and the State Block Data classes. Each of these will be discussed further in the next section as we develop an example property package.\n",
+ "Thus, the calculations of thermophysical properties within the IDAES modeling framework is achieved using a “package” of three related modeling components (or classes); the Physical Parameter Block, the State Block and the State Block Data classes. Each of these will be discussed further in the next section as we develop an example property package.\n",
"\n",
"At a deeper level, the calculation for many thermophysical properties is a self-contained correlation that is more or less independent of the other properties around it. Thus, each set of thermophysical property calculations is a package of user-chosen sub-models for each property of interest to the user.\n",
"\n",
@@ -232,7 +232,7 @@
"\n",
"The first step is to define the units of measurement for the property package, which will in turn be inherited by any unit model using this property package. Units of measurement for the property package are defined by setting units for the 7 base measurement quantities; time, length, mass, amount, temperature, current and luminous intensity (as current and luminous intensity are generally of lesser importance in process systems engineering, specifying units for these base quantities is optional). Within IDAES, units are specified using Pyomo's units of measurement features, which can be imported from `pyomo.environ`. For this example, the units of measurement features were given the name `pyunits` for clarity.\n",
"\n",
- "The units of measurement for all other quantities in the model can then be derived from these base quantities; for example the units of energy are `mass*length^2/time^2`. The framework expects all quantities in the property package to use these base units \u2013 the Pyomo units of measurement conversion tools can be used if conversion between different sets of units are required.\n",
+ "The units of measurement for all other quantities in the model can then be derived from these base quantities; for example the units of energy are `mass*length^2/time^2`. The framework expects all quantities in the property package to use these base units – the Pyomo units of measurement conversion tools can be used if conversion between different sets of units are required.\n",
"\n",
"In order to set the base units, we need to create a dictionary which has each of the base quantities as a key, and provide a Pyomo recognized unit as the value as shown below."
]
@@ -258,7 +258,7 @@
"source": [
"## Step 2: Define Supported Properties\n",
"\n",
- "The next step is to provide some metadata defining what properties are supported by the property package (including state variables). The first purpose of this metadata is to record a summary of what properties are supported to help user identify whether a given property package is suitable for their needs. The second purpose of the metadata is to allow us to simplify our property calculations by only construction those properties that are actually required by a given unit operation \u2013 a property package needs to support all the properties required by a process flowsheet, but not all of those properties are required in every unit operation. Thus, the IDAES modeling framework supports a \u201cbuild-on-demand\u201d approach for properties, such that only those properties that are required are constructed at any given point.\n",
+ "The next step is to provide some metadata defining what properties are supported by the property package (including state variables). The first purpose of this metadata is to record a summary of what properties are supported to help user identify whether a given property package is suitable for their needs. The second purpose of the metadata is to allow us to simplify our property calculations by only construction those properties that are actually required by a given unit operation – a property package needs to support all the properties required by a process flowsheet, but not all of those properties are required in every unit operation. Thus, the IDAES modeling framework supports a “build-on-demand” approach for properties, such that only those properties that are required are constructed at any given point.\n",
"\n",
"This is achieved through the use of the properties metadata, where for each property supported by the property package the user needs to define a `method` argument. This argument can take one of two forms:\n",
"\n",
@@ -291,7 +291,7 @@
"source": [
"## Step 3: Define Component and Phase Lists\n",
"\n",
- "The next step in writing the Physical Parameter Block class is to define the phases and components present in the mixture. These are defined using `Phase` and `Component` objects which are imported from `idaes.core`. As `Phase` and `Component` objects are added to the proeprty package, the `phase_list` and `component_list` `Sets` required by the modeling framework are automatically populated. Even for systems where there is only a single phase or component, it is necessary to define phase and component objects as these are used to construct the necessary indexing sets used when building unit models.\n",
+ "The next step in writing the Physical Parameter Block class is to define the phases and components present in the mixture. These are defined using `Phase` and `Component` objects which are imported from `idaes.core`. As `Phase` and `Component` objects are added to the property package, the `phase_list` and `component_list` `Sets` required by the modeling framework are automatically populated. Even for systems where there is only a single phase or component, it is necessary to define phase and component objects as these are used to construct the necessary indexing sets used when building unit models.\n",
"\n",
"For this example, we have 5 components of interest; benzene, toluene, hydrogen, methane and diphenyl. We define these in the property package by adding a generic `Component` object to the Physical Parameter Block; for example `self.benzene = Component()`. For more complex systems, IDAES supports a number of different component types and components can be assigned a number of arguments at constructions but these will not be discussed here.\n",
"\n",
@@ -327,9 +327,9 @@
"
\n",
"\n",
"For this example, the first parameters we need to define are the reference state for our property calculations along with the molecular weights of each of the components of interest. These are fixed parameters that should not be estimated by parameter estimation, so we create Pyomo `Param` objects to represent each of these, as shown below. When we declare a `Param`, we also need to define a default value and the units of measurement for each parameter. Note that the units of measurement for these parameters does not necessarily need to match those defined in the properties metadata, but if they are not consistent then a unit conversion will be required at some point when calculating property values.\n",
@@ -371,15 +371,15 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "For this example, we also need to define the parameter associated with calculating the specific enthalpy of each component. As mentioned before, we will use the correlation proposed in \u201cThe Properties of Gases and Liquids, 4th Edition\u201d by Reid, Prausnitz and Polling (1987), which has the form:\n",
+ "For this example, we also need to define the parameter associated with calculating the specific enthalpy of each component. As mentioned before, we will use the correlation proposed in “The Properties of Gases and Liquids, 4th Edition” by Reid, Prausnitz and Polling (1987), which has the form:\n",
"\n",
"\\begin{equation*}\n",
- "h_j \u2013 h_{j, ref}= A_j \\times (T-T_{ref}) + \\frac{B_j}{2}\\times (T^2-T_{ref}^2) + \\frac{C_j}{3}\\times (T^3-T_{ref}^3) + \\frac{D_j}{4}\\times (T^4-T_{ref}^4)\n",
+ "h_j – h_{j, ref}= A_j \\times (T-T_{ref}) + \\frac{B_j}{2}\\times (T^2-T_{ref}^2) + \\frac{C_j}{3}\\times (T^3-T_{ref}^3) + \\frac{D_j}{4}\\times (T^4-T_{ref}^4)\n",
"\\end{equation*}\n",
"\n",
- "where $h_{j, ref}$ is the standard heat of formation of component $j$ in the vapor phase, and $A_j$, $B_j$, $C_j$, and $D_j$ are component-specific parameters in the correlation. At first glance, one might ask if we could declare a single object indexed by the list `[\u201cA\u201d, \u201cB\u201d, \u201cC\u201d, \u201cD\u201d]` and component to represent all the parameters as a single object; however it must be noted that the parameters $A$, $B$, $C$, and $D$ all have different units. Thus, we need to declare separate objects for each of $A$, $B$, $C$, and $D$ (along with $h_{ref}$) which are indexed by component so that we can assign the correct units to each.\n",
+ "where $h_{j, ref}$ is the standard heat of formation of component $j$ in the vapor phase, and $A_j$, $B_j$, $C_j$, and $D_j$ are component-specific parameters in the correlation. At first glance, one might ask if we could declare a single object indexed by the list `[“A”, “B”, “C”, “D”]` and component to represent all the parameters as a single object; however it must be noted that the parameters $A$, $B$, $C$, and $D$ all have different units. Thus, we need to declare separate objects for each of $A$, $B$, $C$, and $D$ (along with $h_{ref}$) which are indexed by component so that we can assign the correct units to each.\n",
"\n",
- "However, these parameters are mostly empirical and are values that we may wish to estimate at some point, thus we will declare these as Pyomo `Var` objects rather than `Param` objects, which also means that we must `fix` the value of these parameters when we construct the property package. This is shown in the code below \u2013 note that each parameters (`Var` object is fixed immediately after it is declared)."
+ "However, these parameters are mostly empirical and are values that we may wish to estimate at some point, thus we will declare these as Pyomo `Var` objects rather than `Param` objects, which also means that we must `fix` the value of these parameters when we construct the property package. This is shown in the code below – note that each parameters (`Var` object is fixed immediately after it is declared)."
]
},
{
@@ -478,9 +478,9 @@
"\n",
"First, we need to declare our new class and give it a unique name. In this example, we will call our new class `HDAParameterBlock`. The first two lines of the example below show how we declare our new class using the `declare_process_block_decorator` and inheriting from the `PhysicalParameterBlock` base class from the IDAES Core model libraries. Inheriting from the `PhysicalParameterBlock` brings us access to all the necessary features required by the IDAES modeling framework, whilst the `declare_process_block_class` decorator performs some boilerplate operations to replicate the expected object structure of Pyomo. Further details on these components can be found in the IDAES documentation.\n",
"\n",
- "Next, we need to set up any configuration arguments we need for the property package. This is done using Pyomo \u201cConfig Blocks\u201d which provide a convenient way of declaring, organizing and documenting configuration arguments. To begin with, we can inherit from the `CONFIG` block declared in the `PhysicalParameterBlock` base class, which provides all the arguments that the IDAES modeling framework expects to be present. Modelers can then add additional configuration arguments to provide users with options when constructing their property packages, however we will not cover that in this tutorial.\n",
+ "Next, we need to set up any configuration arguments we need for the property package. This is done using Pyomo “Config Blocks” which provide a convenient way of declaring, organizing and documenting configuration arguments. To begin with, we can inherit from the `CONFIG` block declared in the `PhysicalParameterBlock` base class, which provides all the arguments that the IDAES modeling framework expects to be present. Modelers can then add additional configuration arguments to provide users with options when constructing their property packages, however we will not cover that in this tutorial.\n",
"\n",
- "The most significant part of any IDAES model class is the `build` method, which contains the instructions on how to construct an instance of the desired model and all IDAES models are expected to have a `build` method. The first step in any `build` method is to call `super().build()`, which will trigger the `build` method of the base class that the current class inherits from \u2013 this is important since this is how we automate construction of any underlying components required by the modeling framework and ensure that everything integrates smoothly. Next, a `PhysicalParameterBlock` needs to contain a pointer to the related `StateBlock` (which we will look at next) \u2013 this is used to allow us to build instances of the `StateBlock` by only knowing the `PhysicalParameterBlock` we wish to use. To do this, we create an attribute named `_state_block_class` attached to our class with a pointer to the `StateBlock` class; in this case `self._state_block_class = HDAStateBlock`, where `HDAStateBlock` is the name of the yet to be declared `StateBlock`. Finally, the `build` method needs to construct the actual parameters required for the property package, which we do here by calling the sub-methods written previously.\n",
+ "The most significant part of any IDAES model class is the `build` method, which contains the instructions on how to construct an instance of the desired model and all IDAES models are expected to have a `build` method. The first step in any `build` method is to call `super().build()`, which will trigger the `build` method of the base class that the current class inherits from – this is important since this is how we automate construction of any underlying components required by the modeling framework and ensure that everything integrates smoothly. Next, a `PhysicalParameterBlock` needs to contain a pointer to the related `StateBlock` (which we will look at next) – this is used to allow us to build instances of the `StateBlock` by only knowing the `PhysicalParameterBlock` we wish to use. To do this, we create an attribute named `_state_block_class` attached to our class with a pointer to the `StateBlock` class; in this case `self._state_block_class = HDAStateBlock`, where `HDAStateBlock` is the name of the yet to be declared `StateBlock`. Finally, the `build` method needs to construct the actual parameters required for the property package, which we do here by calling the sub-methods written previously.\n",
"\n",
"The final step in creating the `PhysicalParameterBlock` class is to declare a `classmethod` named `define_metadata` which takes two arguments; a class (`cls`) and an instance of that class (`obj`). This method in turn needs to call two pre-defined methods (inherited from the underlying base classes):\n",
"\n",
@@ -526,13 +526,13 @@
"\n",
"After the `Physical Parameter Block` class has been created, the next step is to write the code necessary to create the State Blocks that will be used through out the flowsheet. Unlike other models however, creating a `State Block` actually required us to write two `classes`. In short, indexed Pyomo object components (e.g. `Vars` and `Blocks`) actually consist of two objects: an `IndexedComponent` object which serves as a container for multiple `ComponentData` objects which represent the component at each point in the indexing set. For example, a `Var` indexed by the `Set` `[1, 2, 3, 4]` actually consists of a single `IndexedVar` object which contains 4 `VarData` objects. Normally this behavior is hidden behind the `declare_process_block_data` decorator which handles the details of this structure (as a side note, unindexed components similarly involve two classes but this is hidden by the use of multiple inheritance.)\n",
"\n",
- "Normally, when we write models in IDAES, we are concerned only with the `ComponentData` object \u2013 i.e., the instructions on how to build an instance of the model at each indexed point (hence the naming convention used when declaring classes). However, State Blocks are slightly different in that we always expect State Blocks to be indexed (they will always be indexed by time, at a minimum). Due to this, we often want to perform actions on all the elements of the indexed `State Block` at once (rather than element by element), such as during initialization. Thus, we have a need to write methods that are attached to the `IndexedStateBlock` in addition to the normal methods for the `StateBlockData` object. Fortunately, the `declare_process_block_data` decorator facilitates this for us, but it does mean we need to declare two classes when creating State Blocks.\n",
+ "Normally, when we write models in IDAES, we are concerned only with the `ComponentData` object – i.e., the instructions on how to build an instance of the model at each indexed point (hence the naming convention used when declaring classes). However, State Blocks are slightly different in that we always expect State Blocks to be indexed (they will always be indexed by time, at a minimum). Due to this, we often want to perform actions on all the elements of the indexed `State Block` at once (rather than element by element), such as during initialization. Thus, we have a need to write methods that are attached to the `IndexedStateBlock` in addition to the normal methods for the `StateBlockData` object. Fortunately, the `declare_process_block_data` decorator facilitates this for us, but it does mean we need to declare two classes when creating State Blocks.\n",
"\n",
"For this example, we will begin by describing the content of the `StateBlockData` objects, as this is where we create the variables and constraints that describe how to calculate the thermophysical properties of the material. After that, we will discuss how to create the class that contains methods to be applied to the `IndexedStateBlock` as a whole.\n",
"\n",
"## Step 5: Declare State Variables\n",
"\n",
- "The first step in defining a `State Block` is to create the \u201cstate variables\u201d which will be used to define the \u201cstate\u201d of the material at any given point. The concept of a \u201cstate variable\u201d in IDAES is much the same as the concept in thermodynamics, with the exception that we include extensive flow information in the state definition in IDAES. In short, the \u201cstate variables\u201d should be sufficient to fully define the state of the material (both extensive and intensive), and should result in a `State Block` with zero degrees of freedom if all the state variables are fixed.\n",
+ "The first step in defining a `State Block` is to create the “state variables” which will be used to define the “state” of the material at any given point. The concept of a “state variable” in IDAES is much the same as the concept in thermodynamics, with the exception that we include extensive flow information in the state definition in IDAES. In short, the “state variables” should be sufficient to fully define the state of the material (both extensive and intensive), and should result in a `State Block` with zero degrees of freedom if all the state variables are fixed.\n",
"\n",
"For this example, our state variables will be:\n",
"\n",
@@ -614,7 +614,7 @@
"2. by using an `Expression`, or,\n",
"3. by using a `Reference`.\n",
"\n",
- "The different between the first two options is that an `Expression` does not appear in the problem passed to the solver \u2013 the `Expression` can be evaluated by the user and included in constraints in the same way as a variable, but when the problem is passed to the solver the `Expression` object is substituted for the expression it represents wherever it appears in the model. This means that there are fewer variables and constraints in the problem the solver sees, but that the constraints that do appear are more complex. There is no simple answer to which approach is best, and different applications may see better results with one form or the other. The third option, using a `Reference` is for cases where a property already exists elsewhere in the model, and we just want to create a local copy of the same object. In terms of properties, this most often occurs with fixed quantities which are declared in the Physical Parameter Block such as molecular weights. For the purposes of this example, we will demonstrate all of these approaches. \n",
+ "The different between the first two options is that an `Expression` does not appear in the problem passed to the solver – the `Expression` can be evaluated by the user and included in constraints in the same way as a variable, but when the problem is passed to the solver the `Expression` object is substituted for the expression it represents wherever it appears in the model. This means that there are fewer variables and constraints in the problem the solver sees, but that the constraints that do appear are more complex. There is no simple answer to which approach is best, and different applications may see better results with one form or the other. The third option, using a `Reference` is for cases where a property already exists elsewhere in the model, and we just want to create a local copy of the same object. In terms of properties, this most often occurs with fixed quantities which are declared in the Physical Parameter Block such as molecular weights. For the purposes of this example, we will demonstrate all of these approaches. \n",
"\n",
"You may recall from the initial problem statement that we have three properties of interest in this example:\n",
"\n",
@@ -658,7 +658,7 @@
"where $x_j$ is the mole fraction of component $j$. Recall that for this example we are using the following correlation for the component specific enthalpies.\n",
"\n",
"\\begin{equation*}\n",
- "h_j \u2013 h_{j, ref}= A_j \\times (T-T_{ref}) + \\frac{B_j}{2}\\times (T^2-T_{ref}^2) + \\frac{C_j}{3}\\times (T^3-T_{ref}^3) + \\frac{D_j}{4}\\times (T^4-T_{ref}^4)\n",
+ "h_j – h_{j, ref}= A_j \\times (T-T_{ref}) + \\frac{B_j}{2}\\times (T^2-T_{ref}^2) + \\frac{C_j}{3}\\times (T^3-T_{ref}^3) + \\frac{D_j}{4}\\times (T^4-T_{ref}^4)\n",
"\\end{equation*}\n",
"\n",
"For the specific enthalpy, we will create a Pyomo `Expression` rather than a `Var` and `Constraint`. In practice, this is much like creating a `Constraint`. However, rather than returning an equality between two expressions, an `Expression` requires a single numerical expression that can be used to compute the quantity of interest.\n",
@@ -736,16 +736,16 @@
"\n",
"### Writing the Initialization Routine\n",
"\n",
- "For initializing State Blocks, the first step is to get our model to a state where it has no degrees of freedom. As mentioned earlier, fixing all of the state variables should be sufficient to fully define the state of the material \u2013 i.e. no degrees of freedom. Additionally, we want to initialize our State Block at a set of conditions that are good initial guesses for the final state of the model once it is finally solved. Of course, the State Block has no way of knowing what these initial values should be, so we depend on the unit model (or the end-user) to provide us with a set of initial values to use \u2013 this is done through a `dict` which we generally call `state_args` where the keys are the names of the state variables and the values are the initial guesses.\n",
+ "For initializing State Blocks, the first step is to get our model to a state where it has no degrees of freedom. As mentioned earlier, fixing all of the state variables should be sufficient to fully define the state of the material – i.e. no degrees of freedom. Additionally, we want to initialize our State Block at a set of conditions that are good initial guesses for the final state of the model once it is finally solved. Of course, the State Block has no way of knowing what these initial values should be, so we depend on the unit model (or the end-user) to provide us with a set of initial values to use – this is done through a `dict` which we generally call `state_args` where the keys are the names of the state variables and the values are the initial guesses.\n",
"\n",
- "Before we start fixing the state variables, there is the possibility that all the state variables have already been fixed (e.g. by a the unit model during its own initialization routine). To allow us to save some time, we include a `state_vars_fixed` argument in our State Block initialization methods that lets the unit model tell us if the state variables are already fixed \u2013 if this is `True` then we know we can skip the step of checking the state variables ourselves. If `state_vars_fixed is False` however, then we need to go and fix all the state variables as part of our initialization routine. To save us the effort of having to code all of this ourselves, the IDAES toolkit contains a utility method named `fix_state_vars` (which we imported earlier), which takes the `state_args` `dict` and then iterates through all the state variables as defined by the State Block (using the `dict` we declared earlier in the `return_state_var_dict` sub-method). This method iterates through all the defined state variables and does the following:\n",
+ "Before we start fixing the state variables, there is the possibility that all the state variables have already been fixed (e.g. by a the unit model during its own initialization routine). To allow us to save some time, we include a `state_vars_fixed` argument in our State Block initialization methods that lets the unit model tell us if the state variables are already fixed – if this is `True` then we know we can skip the step of checking the state variables ourselves. If `state_vars_fixed is False` however, then we need to go and fix all the state variables as part of our initialization routine. To save us the effort of having to code all of this ourselves, the IDAES toolkit contains a utility method named `fix_state_vars` (which we imported earlier), which takes the `state_args` `dict` and then iterates through all the state variables as defined by the State Block (using the `dict` we declared earlier in the `return_state_var_dict` sub-method). This method iterates through all the defined state variables and does the following:\n",
"\n",
"1. If the variable is already fixed, it records this and does nothing. If a variable is already fixed, we assume it was fixed for a reason and that we should not change its value.\n",
"2. If the variable is not fixed, this is recorded and the method then checks the `state_args` dict for an initial guess for the variable. If a value is found, the variable is fixed to this value; otherwise, the variable is fixed to its
.\n",
"\n",
"Finally, the `fix_state_vars` method returns a `dict` that records which variables were fixed by the method, so that we can later reverse these changes. In the example below, we refer to this `dict` as `flags`.\n",
"\n",
- "At this point, all the state variables should now be fixed, but once again we have a small catch \u2013 if we fix all the state variables then we have a situation similar to the inlet of a unit where we cannot write a constraint on the sum of mole fractions and still solve the model. Thus we need to deactivate this constraint
it exists (remembering that this constraint will not exist in all State Blocks). We know that this constraint will only exist if `defined_state is False`, so we start by writing an `IF` statement to check for this and then use the Pyomo `deactivate()` method to deactivate the constraint (remembering that we will need to reactivate it later).\n",
+ "At this point, all the state variables should now be fixed, but once again we have a small catch – if we fix all the state variables then we have a situation similar to the inlet of a unit where we cannot write a constraint on the sum of mole fractions and still solve the model. Thus we need to deactivate this constraint
it exists (remembering that this constraint will not exist in all State Blocks). We know that this constraint will only exist if `defined_state is False`, so we start by writing an `IF` statement to check for this and then use the Pyomo `deactivate()` method to deactivate the constraint (remembering that we will need to reactivate it later).\n",
"\n",
"Before we move on however, it is probably a good idea to check the degrees of freedom to be sure that they are zero (as expected). There are a number of ways things could go wrong (e.g., the unit model said the state variables were fixed when not all of them were, or we missed a constraint we need to deactivate), so a quick check now might save someone a lot of pain in the future. We can use the IDAES `degrees_of_freedom` method to check the degrees of freedom of our State Block, and if this is not zero raise an `Exception` to let the user know something went wrong."
]
@@ -788,7 +788,7 @@
"\n",
"Before we call the solver, we first need to make sure there is actually something to solve; depending on how the State Block is written (e.g. build-on-demand properties and use of `Expressions`), it is sometimes possible that there are actually no `Constraints` to be solved in the model. If we try to send a problem like that to a solver, we will likely get back an error message which is not what we want to see. Whilst we know that our State Block will always contain at least one constraint (for mixture density), we will add a check here anyway to show how it is done. First ,we create a counter to keep track of the number of unfixed variables in the system, `free_vars`. Then we iterate over all the elements of the `blk` (the `IndexedStateBlock`) and check how many free variables are in each. We use the `number_unfixed_variables()` method from the `idaes.core.util.model_statistics` module to do this, and add the result `free_vars` for each element. If the final value of `free_vars` is not zero, then we know there is something to solve for and we can proceed to call a solver; otherwise we know that we can skip this step.\n",
"\n",
- "In order to solve the entire `IndexedStateBlock`, we need to do things slightly differently than normal. The standard Pyomo `SolverFactory` cannot be applied to indexed blocks, so instead we use the IDAES `solve_indexed_block` method (imported from `idaes.core.initialization`) which puts a wrapper around the indexed block so that we can use Pyomo\u2019s solver interface. In order to use this method, we need to provide a Pyomo `SolverFactory` object (called `solver` here, which also includes any attached solver options) along with the `blk` we wish to solve and where to send the solver results (the `tee` argument). Additionally, we want the user to have the ability to control the output from the solver through the IDAES logger interface, which we do by wrapping the solver call with the following line of code:\n",
+ "In order to solve the entire `IndexedStateBlock`, we need to do things slightly differently than normal. The standard Pyomo `SolverFactory` cannot be applied to indexed blocks, so instead we use the IDAES `solve_indexed_block` method (imported from `idaes.core.initialization`) which puts a wrapper around the indexed block so that we can use Pyomo’s solver interface. In order to use this method, we need to provide a Pyomo `SolverFactory` object (called `solver` here, which also includes any attached solver options) along with the `blk` we wish to solve and where to send the solver results (the `tee` argument). Additionally, we want the user to have the ability to control the output from the solver through the IDAES logger interface, which we do by wrapping the solver call with the following line of code:\n",
"\n",
"```\n",
"with idaeslog.solver_log(solve_log, idaeslog.DEBUG) as slc:\n",
@@ -796,7 +796,7 @@
"\n",
"where `idaeslog` is an instance of the IDAES logger. Note that we send the solver output to this logger by setting `tee=slc`. In this way, all the output from the solver is passed into the logger allowing users to easily control the output level without needing to send additional arguments to the initialization methods.\n",
"\n",
- "If all goes well, the solver will successfully initialize our model and we can move on. However, sometimes the solver will fail catastrophically, in which case we need to make sure that our initialization routine can attempt to recover. In order to do this, we wrap the solver call within a Python `try/except` statement. This way, if the solver fails badly and returns an `Exception`, we can capture this and decide how to process \u2013 otherwise the execution of our model would terminate with the exception from the solver. In the case we encounter an `Exception` here, we will record `results=None` and try to continue with initializing our model in the hope that we can recover.\n",
+ "If all goes well, the solver will successfully initialize our model and we can move on. However, sometimes the solver will fail catastrophically, in which case we need to make sure that our initialization routine can attempt to recover. In order to do this, we wrap the solver call within a Python `try/except` statement. This way, if the solver fails badly and returns an `Exception`, we can capture this and decide how to process – otherwise the execution of our model would terminate with the exception from the solver. In the case we encounter an `Exception` here, we will record `results=None` and try to continue with initializing our model in the hope that we can recover.\n",
"\n",
"Finally, it is useful to provide the user with some feedback on how the initialization is proceeding. In the last lines below, we send a message to the IDAES logger with a message saying that the initialization step has been completed and append the final solver status."
]
@@ -900,7 +900,7 @@
"As the name suggests, the `initialize` method is used to run the initialization routine for the State Block, and this is where we will use the `prepare_state`, `initialize_state` and `restore_state` methods we wrote previously. The `initialize` method requires the following arguments to be declared:\n",
"\n",
"* `blk`: this will be a pointer to an instance of the State Block to be initialized.\n",
- "* `state_args`: this is used to pass the \u2018dict\u2019 of initial guesses to the initialization routine. This should default to `None` if not provided. The `fix_state_vars` method will interpret a value of `None` as no guesses provided as use the current values instead.\n",
+ "* `state_args`: this is used to pass the ‘dict’ of initial guesses to the initialization routine. This should default to `None` if not provided. The `fix_state_vars` method will interpret a value of `None` as no guesses provided as use the current values instead.\n",
"* `solver`: this argument is used to allow tell the State Block to use a specific solver during initialization, and should be a string recognized by the Pyomo `SolverFactory`. We generally set this to `None` in order to signify that IDAES Should use the default solver (which is IPOPT).\n",
"* `optarg`: this argument is used to set any solver options the user desires. Again this is generally set to `None` to indicate that the default solver settings should be used.\n",
"* `state_vars_fixed`: argument to allow the unit model to inform the State Block that the state variables are already fixed. This should default to `False`.\n",
@@ -959,13 +959,13 @@
"source": [
"### The StateBlockData class\n",
"\n",
- "Finally, we can build the `StateBlockData` class, which we will call `HDAStateBlockData`. First, we use the `declare_process_block_class` decorator but this time we provide two arguments. The first argument is the name of the class that will be automatically constructed for us (`HDAStateBlock`) whilst the second argument is a reference to the class we wish to use as the base when building the `IndexedHDAStateBlock` class \u2013 i.e. the `_HDAStateBlock` class we just declared. Then, we declare our new `HDAStateBlockData` class and inherit from the IDAES `StateBlockData` base class.\n",
+ "Finally, we can build the `StateBlockData` class, which we will call `HDAStateBlockData`. First, we use the `declare_process_block_class` decorator but this time we provide two arguments. The first argument is the name of the class that will be automatically constructed for us (`HDAStateBlock`) whilst the second argument is a reference to the class we wish to use as the base when building the `IndexedHDAStateBlock` class – i.e. the `_HDAStateBlock` class we just declared. Then, we declare our new `HDAStateBlockData` class and inherit from the IDAES `StateBlockData` base class.\n",
"\n",
"As usual, the first thing we need to define in our new class is a `build` method, where we will provide the instructions for constructing our property model, and once again the first thing we should do is call `super().build()` to construct all the underlying components defined by the parent class. After this, we can call the methods we wrote earlier to construct the state variables and the add the calculations for the properties of interest.\n",
"\n",
- "However, if you recall from when we defined the properties metadata at the beginning of the example, we decided that the specific molar enthalpy of the mixture would be a \u201cbuild-on-demand\u201d property (i.e., we provided a specific method in the properties metadata rather than `None`). Thus, we do not want to call the method to construct the specific molar enthalpy as part of the `build` method, meaning that we only call the `add_state_variables`, `add_mole_fraction_constraint` and `add_molecular_weight_and_density` as in the `build` method.\n",
+ "However, if you recall from when we defined the properties metadata at the beginning of the example, we decided that the specific molar enthalpy of the mixture would be a “build-on-demand” property (i.e., we provided a specific method in the properties metadata rather than `None`). Thus, we do not want to call the method to construct the specific molar enthalpy as part of the `build` method, meaning that we only call the `add_state_variables`, `add_mole_fraction_constraint` and `add_molecular_weight_and_density` as in the `build` method.\n",
"\n",
- "To add the specific molar enthalpy calculation as a \u201cbuild-on-demand\u201d property, we instead declare a separate method with the name we provided in the properties metadata. Whenever the specific molar enthalpy is required by a unit model it will check to see if the property already exists, and if not it will look up the properties metadata and call the method listed there; i.e. `_enth_mol` in this case. Thus, we declare another method on our `HDAStateBlockData` class named `enth_mol` which takes only the class instance as an argument (`self`), and then call the `add_enth_mol` method we created earlier to construct the required `Expression`.\n",
+ "To add the specific molar enthalpy calculation as a “build-on-demand” property, we instead declare a separate method with the name we provided in the properties metadata. Whenever the specific molar enthalpy is required by a unit model it will check to see if the property already exists, and if not it will look up the properties metadata and call the method listed there; i.e. `_enth_mol` in this case. Thus, we declare another method on our `HDAStateBlockData` class named `enth_mol` which takes only the class instance as an argument (`self`), and then call the `add_enth_mol` method we created earlier to construct the required `Expression`.\n",
"\n",
"That is all we need to do in order to construct the variables and constraints we need for the property calculations. However, there are a number of other things we need to define in our State Block Data class. In order to provide much of the flexibility present in the IDAES modeling framework, we defer making decisions on much of the form of the overall model for as long as possible. However, these decisions need to be made at some point, and the State Block Data is where this finally occurs.\n",
"\n",
@@ -983,7 +983,7 @@
"* `default_material_balance_type` should return an instance of the IDAES `MaterialBalanceType` `Enum` (imported from `idaes.core`).\n",
"* `default_energy_balance_type` should return an instance of the IDAES `EnergyBalanceType` `Enum` (imported from `idaes.core`).\n",
"\n",
- "Finally, we need to specify the basis of the material flow terms (mass, mole or other). This is used to automatically convert between different bases as required (e.g. a user can define a custom mass transfer term on a molar basis whilst using a mass basis for the actual material balance). Note that automatic conversion only works for mass and molar basis; the \u201cother\u201d basis is used to indicate forms which cannot be easily converted (i.e., the modeler needs to handle this manually). To define the material flow term basis we define a final method named `get_material_flow_basis` which returns an instance of the IDAES `MaterialFlowBasis` `Enum` (again imported from `idaes.core`)."
+ "Finally, we need to specify the basis of the material flow terms (mass, mole or other). This is used to automatically convert between different bases as required (e.g. a user can define a custom mass transfer term on a molar basis whilst using a mass basis for the actual material balance). Note that automatic conversion only works for mass and molar basis; the “other” basis is used to indicate forms which cannot be easily converted (i.e., the modeler needs to handle this manually). To define the material flow term basis we define a final method named `get_material_flow_basis` which returns an instance of the IDAES `MaterialFlowBasis` `Enum` (again imported from `idaes.core`)."
]
},
{
@@ -1055,9 +1055,9 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "Next, we create `ConcreteModel` and a steady-state `FlowsheetBlock` to contain our example, ot which we attach an instance of our new `HDAPhysicalParameterBlock`.\n",
+ "Next, we create `ConcreteModel` and a steady-state `FlowsheetBlock` to contain our example, to which we attach an instance of our new `HDAPhysicalParameterBlock`.\n",
"\n",
- "We can then create an instance of the `HDAStateBlock` directly from the parameter block using the `build_state_block` method. This uses the reference to the State Block class that we attached ot the Physical Parameter Block earlier in the example to automatically create an instance of the correct class. Note that we index the State Block by the time domain, so that it looks like a typical state block in a flowsheet, and we set `defined_state = True` so that we can set values for all the component mole fractions later."
+ "We can then create an instance of the `HDAStateBlock` directly from the parameter block using the `build_state_block` method. This uses the reference to the State Block class that we attached to the Physical Parameter Block earlier in the example to automatically create an instance of the correct class. Note that we index the State Block by the time domain, so that it looks like a typical state block in a flowsheet, and we set `defined_state = True` so that we can set values for all the component mole fractions later."
]
},
{
@@ -1079,7 +1079,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "We now have an instance of our new State Block in our flowsheet, so let\u2019s display it and see what it contains."
+ "We now have an instance of our new State Block in our flowsheet, so let’s display it and see what it contains."
]
},
{
@@ -1095,7 +1095,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "We can see that our State Block contains a single point in time, which in turn contains the five variables. These are our four state variables (molar flow rate, component mole fraction, temperature and pressure) as well as the mixture density. We also have a single constraint, which is the ideal gas equation used to calculate density. Note that we don\u2019t see the component molecular weights as they are `Params` (`References` take on the appearance of the component being referenced) or the molar enthalpy as it is an `Expression`, not a variable (plus it hasn\u2019t been constructed yet as we haven\u2019t asked for it).\n",
+ "We can see that our State Block contains a single point in time, which in turn contains the five variables. These are our four state variables (molar flow rate, component mole fraction, temperature and pressure) as well as the mixture density. We also have a single constraint, which is the ideal gas equation used to calculate density. Note that we don’t see the component molecular weights as they are `Params` (`References` take on the appearance of the component being referenced) or the molar enthalpy as it is an `Expression`, not a variable (plus it hasn’t been constructed yet as we haven’t asked for it).\n",
"\n",
"Next, let us check the degrees of freedom in our State Block."
]
@@ -1131,7 +1131,7 @@
"source": [
"This is unexpected: the `degrees_of_freedom` method is saying there are only 2 degrees of freedom in our State Block, but there are 8 state variables.\n",
"\n",
- "However, if we think about the constraints we have written, we are only actually using 2 of the state variables in any constraint (temperature and pressure appear in the ideal gas equation). The molar flowrate and component mole fractions are not actually used anywhere in our model, so they have been excluded from the degrees of freedom calculation. In Pyomo terminology, these variables are \u201cStale\u201d, and they will not be sent to the solver when it is called. Thus, the two degrees of freedom is in fact correct.\n",
+ "However, if we think about the constraints we have written, we are only actually using 2 of the state variables in any constraint (temperature and pressure appear in the ideal gas equation). The molar flowrate and component mole fractions are not actually used anywhere in our model, so they have been excluded from the degrees of freedom calculation. In Pyomo terminology, these variables are “Stale”, and they will not be sent to the solver when it is called. Thus, the two degrees of freedom is in fact correct.\n",
"\n",
"Note that this is only the case because our property package is so simple. Also, the specific enthalpy calculation depends on the component mole fractions, so whilst we could solve the State Block by only specifying temperature and pressure, the value of the specific molar enthalpy would be meaningless.\n",
"\n",
@@ -1158,7 +1158,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "Now that we have fixed the values for all the state variables, we would expect that the degrees of freedom should be zero (even though we fixed all 8 variables, only temperature and pressure actually contribute to the degrees of freedom). Let\u2019s check this to be sure."
+ "Now that we have fixed the values for all the state variables, we would expect that the degrees of freedom should be zero (even though we fixed all 8 variables, only temperature and pressure actually contribute to the degrees of freedom). Let’s check this to be sure."
]
},
{
@@ -1406,4 +1406,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/properties/custom/custom_physical_property_packages_usr.ipynb b/idaes_examples/notebooks/docs/properties/custom/custom_physical_property_packages_usr.ipynb
index ef902023..9196bb04 100644
--- a/idaes_examples/notebooks/docs/properties/custom/custom_physical_property_packages_usr.ipynb
+++ b/idaes_examples/notebooks/docs/properties/custom/custom_physical_property_packages_usr.ipynb
@@ -34,7 +34,7 @@
"Maintainer: Andrew Lee \n",
"Updated: 2023-06-01 \n",
"\n",
- "Calculation of thermophysical, transport and reaction properties form a key part of any process model, and it is important that these calculations are both accurate and tractable in order for the overall problem to be solved correctly. One of the features of the IDAES Integrated Platform is the ability for modelers to create their own property \u201cpackages\u201d to calculate these properties, allowing them to customize the level of complexity and rigor to suit each application. This tutorial will introduce you to the basics of creating property packages for calculating thermophysical and transport properties within the IDAES Core Modeling Framework.\n",
+ "Calculation of thermophysical, transport and reaction properties form a key part of any process model, and it is important that these calculations are both accurate and tractable in order for the overall problem to be solved correctly. One of the features of the IDAES Integrated Platform is the ability for modelers to create their own property “packages” to calculate these properties, allowing them to customize the level of complexity and rigor to suit each application. This tutorial will introduce you to the basics of creating property packages for calculating thermophysical and transport properties within the IDAES Core Modeling Framework.\n",
"\n",
"## What is a Property?\n",
"\n",
@@ -50,7 +50,7 @@
"* transport properties such as viscosity and thermal conductivity\n",
"* rates of reaction and chemical equilibria\n",
"\n",
- "The definition and calculation of all of these is defined via \u201cproperty packages\u201d, which contain all the variables and constraints associated with calculating these properties.\n",
+ "The definition and calculation of all of these is defined via “property packages”, which contain all the variables and constraints associated with calculating these properties.\n",
"\n",
"
\n",
"
Note:\n",
@@ -67,19 +67,19 @@
"\n",
"## What Properties do I Need?\n",
"\n",
- "An important aspect of the IDAES Core Modeling Framework is that a modeler only needs to provide calculations for those properties that they will use within their process. Put another way, modelers do not need to include calculations for a property that they are not going to use in their model \u2013 this allows modelers to avoid introducing unnecessary complexity into their models to calculate a property they do not actually need. When combined with flexibility elsewhere in the modeling framework to control which equations are written in the unit models, this can even allow users to avoid calculating properties that would normally be considered mandatory \u2013 for example, a property package for a conceptual design flowsheet which does not include energy or momentum balances would not need to define specific enthalpy or even temperature and pressure as these will not be required by the unit models.\n",
+ "An important aspect of the IDAES Core Modeling Framework is that a modeler only needs to provide calculations for those properties that they will use within their process. Put another way, modelers do not need to include calculations for a property that they are not going to use in their model – this allows modelers to avoid introducing unnecessary complexity into their models to calculate a property they do not actually need. When combined with flexibility elsewhere in the modeling framework to control which equations are written in the unit models, this can even allow users to avoid calculating properties that would normally be considered mandatory – for example, a property package for a conceptual design flowsheet which does not include energy or momentum balances would not need to define specific enthalpy or even temperature and pressure as these will not be required by the unit models.\n",
"\n",
"This then raises the question of how do you know what properties you will need, especially if you are using models from a library you did not write yourself. To answer this, you should refer to the model documentation, and you can also use the [IDAES Properties Interrogator tool](https://idaes-pse.readthedocs.io/en/stable/reference_guides/model_libraries/generic/property_models/interrogator.html) to analyze your flowsheet and determine what properties are required.\n",
"\n",
"## Thermophysical Properties and Reaction Properties\n",
"\n",
- "Within the IDAES Core Modeling Framework, properties are divided into two classifications; thermophysical properties and reaction properties. Reaction properties are those properties related to chemical reactions (both equilibrium and rate-based, but not phase equilibrium) that occur within the system , whilst thermophysical properties include those properties related to thermodynamic relationships (including phase equilibrium) and transport properties. The reason for this separation is that thermophysical properties are required by all unit operations in a process (and need to be consistent with each other), whilst reaction properties are generally only required in specific unit operations identified as \u201creactors\u201d (and each reactor may have a different set of chemical reactions occurring in it). Thus, reaction properties are separated from the thermophysical property calculations to allow for modular implementation in only specific reactor units. This tutorial only deals with thermophysical properties, and reaction properties will be dealt with in a later tutorial.\n",
+ "Within the IDAES Core Modeling Framework, properties are divided into two classifications; thermophysical properties and reaction properties. Reaction properties are those properties related to chemical reactions (both equilibrium and rate-based, but not phase equilibrium) that occur within the system , whilst thermophysical properties include those properties related to thermodynamic relationships (including phase equilibrium) and transport properties. The reason for this separation is that thermophysical properties are required by all unit operations in a process (and need to be consistent with each other), whilst reaction properties are generally only required in specific unit operations identified as “reactors” (and each reactor may have a different set of chemical reactions occurring in it). Thus, reaction properties are separated from the thermophysical property calculations to allow for modular implementation in only specific reactor units. This tutorial only deals with thermophysical properties, and reaction properties will be dealt with in a later tutorial.\n",
"\n",
- "## What is a Property \u201cPackage\u201d?\n",
+ "## What is a Property “Package”?\n",
"\n",
- "Generally, properties (both thermophysical and reaction) are calculated using correlations that depend on some set of parameters (be they physical constants or empirical parameters). These parameters are constant across all instances of a property calculation in a flowsheet (i.e. each StateBlock uses the same parameters), it makes sense to store these parameters in a single, central location that all StateBlocks can refer to as necessary. Thus, the IDAES modeling framework has \u201cParameter Blocks\u201d which are attached to the flowsheet to contain all the global parameters associated with a given set of property calculations.\n",
+ "Generally, properties (both thermophysical and reaction) are calculated using correlations that depend on some set of parameters (be they physical constants or empirical parameters). These parameters are constant across all instances of a property calculation in a flowsheet (i.e. each StateBlock uses the same parameters), it makes sense to store these parameters in a single, central location that all StateBlocks can refer to as necessary. Thus, the IDAES modeling framework has “Parameter Blocks” which are attached to the flowsheet to contain all the global parameters associated with a given set of property calculations.\n",
"\n",
- "Thus, the calculations of thermophysical properties within the IDAES modeling framework is achieved using a \u201cpackage\u201d of three related modeling components (or classes); the Physical Parameter Block, the State Block and the State Block Data classes. Each of these will be discussed further in the next section as we develop an example property package.\n",
+ "Thus, the calculations of thermophysical properties within the IDAES modeling framework is achieved using a “package” of three related modeling components (or classes); the Physical Parameter Block, the State Block and the State Block Data classes. Each of these will be discussed further in the next section as we develop an example property package.\n",
"\n",
"At a deeper level, the calculation for many thermophysical properties is a self-contained correlation that is more or less independent of the other properties around it. Thus, each set of thermophysical property calculations is a package of user-chosen sub-models for each property of interest to the user.\n",
"\n",
@@ -232,7 +232,7 @@
"\n",
"The first step is to define the units of measurement for the property package, which will in turn be inherited by any unit model using this property package. Units of measurement for the property package are defined by setting units for the 7 base measurement quantities; time, length, mass, amount, temperature, current and luminous intensity (as current and luminous intensity are generally of lesser importance in process systems engineering, specifying units for these base quantities is optional). Within IDAES, units are specified using Pyomo's units of measurement features, which can be imported from `pyomo.environ`. For this example, the units of measurement features were given the name `pyunits` for clarity.\n",
"\n",
- "The units of measurement for all other quantities in the model can then be derived from these base quantities; for example the units of energy are `mass*length^2/time^2`. The framework expects all quantities in the property package to use these base units \u2013 the Pyomo units of measurement conversion tools can be used if conversion between different sets of units are required.\n",
+ "The units of measurement for all other quantities in the model can then be derived from these base quantities; for example the units of energy are `mass*length^2/time^2`. The framework expects all quantities in the property package to use these base units – the Pyomo units of measurement conversion tools can be used if conversion between different sets of units are required.\n",
"\n",
"In order to set the base units, we need to create a dictionary which has each of the base quantities as a key, and provide a Pyomo recognized unit as the value as shown below."
]
@@ -258,7 +258,7 @@
"source": [
"## Step 2: Define Supported Properties\n",
"\n",
- "The next step is to provide some metadata defining what properties are supported by the property package (including state variables). The first purpose of this metadata is to record a summary of what properties are supported to help user identify whether a given property package is suitable for their needs. The second purpose of the metadata is to allow us to simplify our property calculations by only construction those properties that are actually required by a given unit operation \u2013 a property package needs to support all the properties required by a process flowsheet, but not all of those properties are required in every unit operation. Thus, the IDAES modeling framework supports a \u201cbuild-on-demand\u201d approach for properties, such that only those properties that are required are constructed at any given point.\n",
+ "The next step is to provide some metadata defining what properties are supported by the property package (including state variables). The first purpose of this metadata is to record a summary of what properties are supported to help user identify whether a given property package is suitable for their needs. The second purpose of the metadata is to allow us to simplify our property calculations by only construction those properties that are actually required by a given unit operation – a property package needs to support all the properties required by a process flowsheet, but not all of those properties are required in every unit operation. Thus, the IDAES modeling framework supports a “build-on-demand” approach for properties, such that only those properties that are required are constructed at any given point.\n",
"\n",
"This is achieved through the use of the properties metadata, where for each property supported by the property package the user needs to define a `method` argument. This argument can take one of two forms:\n",
"\n",
@@ -291,7 +291,7 @@
"source": [
"## Step 3: Define Component and Phase Lists\n",
"\n",
- "The next step in writing the Physical Parameter Block class is to define the phases and components present in the mixture. These are defined using `Phase` and `Component` objects which are imported from `idaes.core`. As `Phase` and `Component` objects are added to the proeprty package, the `phase_list` and `component_list` `Sets` required by the modeling framework are automatically populated. Even for systems where there is only a single phase or component, it is necessary to define phase and component objects as these are used to construct the necessary indexing sets used when building unit models.\n",
+ "The next step in writing the Physical Parameter Block class is to define the phases and components present in the mixture. These are defined using `Phase` and `Component` objects which are imported from `idaes.core`. As `Phase` and `Component` objects are added to the property package, the `phase_list` and `component_list` `Sets` required by the modeling framework are automatically populated. Even for systems where there is only a single phase or component, it is necessary to define phase and component objects as these are used to construct the necessary indexing sets used when building unit models.\n",
"\n",
"For this example, we have 5 components of interest; benzene, toluene, hydrogen, methane and diphenyl. We define these in the property package by adding a generic `Component` object to the Physical Parameter Block; for example `self.benzene = Component()`. For more complex systems, IDAES supports a number of different component types and components can be assigned a number of arguments at constructions but these will not be discussed here.\n",
"\n",
@@ -327,9 +327,9 @@
"
\n",
"Param or Var:\n",
"\n",
- "The most obvious way to declare a \"parameter\" in a model would appear to be to use the Pyomo `Param` object. However, modelers should be aware the `Param` objects are never seen by the solver (they are converted to fixed floating point numbers by the solver writer). This means that it is not possible to use a solver to find the value for a parameter \u2013 i.e., it is not possible to use `Param` objects in a parameter estimation problem.\n",
+ "The most obvious way to declare a \"parameter\" in a model would appear to be to use the Pyomo `Param` object. However, modelers should be aware the `Param` objects are never seen by the solver (they are converted to fixed floating point numbers by the solver writer). This means that it is not possible to use a solver to find the value for a parameter – i.e., it is not possible to use `Param` objects in a parameter estimation problem.\n",
"\n",
- "Instead, modelers should use fixed `Var` objects for any parameter that may need to be estimated at some point. Within IDAES, this means that most \u201cparameters\u201d are in fact declared as `Var` objects, with `Param` objects used only for parameters with well-known values (for example critical pressures and temperatures or molecular weights).\n",
+ "Instead, modelers should use fixed `Var` objects for any parameter that may need to be estimated at some point. Within IDAES, this means that most “parameters” are in fact declared as `Var` objects, with `Param` objects used only for parameters with well-known values (for example critical pressures and temperatures or molecular weights).\n",
"
\n",
"\n",
"For this example, the first parameters we need to define are the reference state for our property calculations along with the molecular weights of each of the components of interest. These are fixed parameters that should not be estimated by parameter estimation, so we create Pyomo `Param` objects to represent each of these, as shown below. When we declare a `Param`, we also need to define a default value and the units of measurement for each parameter. Note that the units of measurement for these parameters does not necessarily need to match those defined in the properties metadata, but if they are not consistent then a unit conversion will be required at some point when calculating property values.\n",
@@ -371,15 +371,15 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "For this example, we also need to define the parameter associated with calculating the specific enthalpy of each component. As mentioned before, we will use the correlation proposed in \u201cThe Properties of Gases and Liquids, 4th Edition\u201d by Reid, Prausnitz and Polling (1987), which has the form:\n",
+ "For this example, we also need to define the parameter associated with calculating the specific enthalpy of each component. As mentioned before, we will use the correlation proposed in “The Properties of Gases and Liquids, 4th Edition” by Reid, Prausnitz and Polling (1987), which has the form:\n",
"\n",
"\\begin{equation*}\n",
- "h_j \u2013 h_{j, ref}= A_j \\times (T-T_{ref}) + \\frac{B_j}{2}\\times (T^2-T_{ref}^2) + \\frac{C_j}{3}\\times (T^3-T_{ref}^3) + \\frac{D_j}{4}\\times (T^4-T_{ref}^4)\n",
+ "h_j – h_{j, ref}= A_j \\times (T-T_{ref}) + \\frac{B_j}{2}\\times (T^2-T_{ref}^2) + \\frac{C_j}{3}\\times (T^3-T_{ref}^3) + \\frac{D_j}{4}\\times (T^4-T_{ref}^4)\n",
"\\end{equation*}\n",
"\n",
- "where $h_{j, ref}$ is the standard heat of formation of component $j$ in the vapor phase, and $A_j$, $B_j$, $C_j$, and $D_j$ are component-specific parameters in the correlation. At first glance, one might ask if we could declare a single object indexed by the list `[\u201cA\u201d, \u201cB\u201d, \u201cC\u201d, \u201cD\u201d]` and component to represent all the parameters as a single object; however it must be noted that the parameters $A$, $B$, $C$, and $D$ all have different units. Thus, we need to declare separate objects for each of $A$, $B$, $C$, and $D$ (along with $h_{ref}$) which are indexed by component so that we can assign the correct units to each.\n",
+ "where $h_{j, ref}$ is the standard heat of formation of component $j$ in the vapor phase, and $A_j$, $B_j$, $C_j$, and $D_j$ are component-specific parameters in the correlation. At first glance, one might ask if we could declare a single object indexed by the list `[“A”, “B”, “C”, “D”]` and component to represent all the parameters as a single object; however it must be noted that the parameters $A$, $B$, $C$, and $D$ all have different units. Thus, we need to declare separate objects for each of $A$, $B$, $C$, and $D$ (along with $h_{ref}$) which are indexed by component so that we can assign the correct units to each.\n",
"\n",
- "However, these parameters are mostly empirical and are values that we may wish to estimate at some point, thus we will declare these as Pyomo `Var` objects rather than `Param` objects, which also means that we must `fix` the value of these parameters when we construct the property package. This is shown in the code below \u2013 note that each parameters (`Var` object is fixed immediately after it is declared)."
+ "However, these parameters are mostly empirical and are values that we may wish to estimate at some point, thus we will declare these as Pyomo `Var` objects rather than `Param` objects, which also means that we must `fix` the value of these parameters when we construct the property package. This is shown in the code below – note that each parameters (`Var` object is fixed immediately after it is declared)."
]
},
{
@@ -478,9 +478,9 @@
"\n",
"First, we need to declare our new class and give it a unique name. In this example, we will call our new class `HDAParameterBlock`. The first two lines of the example below show how we declare our new class using the `declare_process_block_decorator` and inheriting from the `PhysicalParameterBlock` base class from the IDAES Core model libraries. Inheriting from the `PhysicalParameterBlock` brings us access to all the necessary features required by the IDAES modeling framework, whilst the `declare_process_block_class` decorator performs some boilerplate operations to replicate the expected object structure of Pyomo. Further details on these components can be found in the IDAES documentation.\n",
"\n",
- "Next, we need to set up any configuration arguments we need for the property package. This is done using Pyomo \u201cConfig Blocks\u201d which provide a convenient way of declaring, organizing and documenting configuration arguments. To begin with, we can inherit from the `CONFIG` block declared in the `PhysicalParameterBlock` base class, which provides all the arguments that the IDAES modeling framework expects to be present. Modelers can then add additional configuration arguments to provide users with options when constructing their property packages, however we will not cover that in this tutorial.\n",
+ "Next, we need to set up any configuration arguments we need for the property package. This is done using Pyomo “Config Blocks” which provide a convenient way of declaring, organizing and documenting configuration arguments. To begin with, we can inherit from the `CONFIG` block declared in the `PhysicalParameterBlock` base class, which provides all the arguments that the IDAES modeling framework expects to be present. Modelers can then add additional configuration arguments to provide users with options when constructing their property packages, however we will not cover that in this tutorial.\n",
"\n",
- "The most significant part of any IDAES model class is the `build` method, which contains the instructions on how to construct an instance of the desired model and all IDAES models are expected to have a `build` method. The first step in any `build` method is to call `super().build()`, which will trigger the `build` method of the base class that the current class inherits from \u2013 this is important since this is how we automate construction of any underlying components required by the modeling framework and ensure that everything integrates smoothly. Next, a `PhysicalParameterBlock` needs to contain a pointer to the related `StateBlock` (which we will look at next) \u2013 this is used to allow us to build instances of the `StateBlock` by only knowing the `PhysicalParameterBlock` we wish to use. To do this, we create an attribute named `_state_block_class` attached to our class with a pointer to the `StateBlock` class; in this case `self._state_block_class = HDAStateBlock`, where `HDAStateBlock` is the name of the yet to be declared `StateBlock`. Finally, the `build` method needs to construct the actual parameters required for the property package, which we do here by calling the sub-methods written previously.\n",
+ "The most significant part of any IDAES model class is the `build` method, which contains the instructions on how to construct an instance of the desired model and all IDAES models are expected to have a `build` method. The first step in any `build` method is to call `super().build()`, which will trigger the `build` method of the base class that the current class inherits from – this is important since this is how we automate construction of any underlying components required by the modeling framework and ensure that everything integrates smoothly. Next, a `PhysicalParameterBlock` needs to contain a pointer to the related `StateBlock` (which we will look at next) – this is used to allow us to build instances of the `StateBlock` by only knowing the `PhysicalParameterBlock` we wish to use. To do this, we create an attribute named `_state_block_class` attached to our class with a pointer to the `StateBlock` class; in this case `self._state_block_class = HDAStateBlock`, where `HDAStateBlock` is the name of the yet to be declared `StateBlock`. Finally, the `build` method needs to construct the actual parameters required for the property package, which we do here by calling the sub-methods written previously.\n",
"\n",
"The final step in creating the `PhysicalParameterBlock` class is to declare a `classmethod` named `define_metadata` which takes two arguments; a class (`cls`) and an instance of that class (`obj`). This method in turn needs to call two pre-defined methods (inherited from the underlying base classes):\n",
"\n",
@@ -526,13 +526,13 @@
"\n",
"After the `Physical Parameter Block` class has been created, the next step is to write the code necessary to create the State Blocks that will be used through out the flowsheet. Unlike other models however, creating a `State Block` actually required us to write two `classes`. In short, indexed Pyomo object components (e.g. `Vars` and `Blocks`) actually consist of two objects: an `IndexedComponent` object which serves as a container for multiple `ComponentData` objects which represent the component at each point in the indexing set. For example, a `Var` indexed by the `Set` `[1, 2, 3, 4]` actually consists of a single `IndexedVar` object which contains 4 `VarData` objects. Normally this behavior is hidden behind the `declare_process_block_data` decorator which handles the details of this structure (as a side note, unindexed components similarly involve two classes but this is hidden by the use of multiple inheritance.)\n",
"\n",
- "Normally, when we write models in IDAES, we are concerned only with the `ComponentData` object \u2013 i.e., the instructions on how to build an instance of the model at each indexed point (hence the naming convention used when declaring classes). However, State Blocks are slightly different in that we always expect State Blocks to be indexed (they will always be indexed by time, at a minimum). Due to this, we often want to perform actions on all the elements of the indexed `State Block` at once (rather than element by element), such as during initialization. Thus, we have a need to write methods that are attached to the `IndexedStateBlock` in addition to the normal methods for the `StateBlockData` object. Fortunately, the `declare_process_block_data` decorator facilitates this for us, but it does mean we need to declare two classes when creating State Blocks.\n",
+ "Normally, when we write models in IDAES, we are concerned only with the `ComponentData` object – i.e., the instructions on how to build an instance of the model at each indexed point (hence the naming convention used when declaring classes). However, State Blocks are slightly different in that we always expect State Blocks to be indexed (they will always be indexed by time, at a minimum). Due to this, we often want to perform actions on all the elements of the indexed `State Block` at once (rather than element by element), such as during initialization. Thus, we have a need to write methods that are attached to the `IndexedStateBlock` in addition to the normal methods for the `StateBlockData` object. Fortunately, the `declare_process_block_data` decorator facilitates this for us, but it does mean we need to declare two classes when creating State Blocks.\n",
"\n",
"For this example, we will begin by describing the content of the `StateBlockData` objects, as this is where we create the variables and constraints that describe how to calculate the thermophysical properties of the material. After that, we will discuss how to create the class that contains methods to be applied to the `IndexedStateBlock` as a whole.\n",
"\n",
"## Step 5: Declare State Variables\n",
"\n",
- "The first step in defining a `State Block` is to create the \u201cstate variables\u201d which will be used to define the \u201cstate\u201d of the material at any given point. The concept of a \u201cstate variable\u201d in IDAES is much the same as the concept in thermodynamics, with the exception that we include extensive flow information in the state definition in IDAES. In short, the \u201cstate variables\u201d should be sufficient to fully define the state of the material (both extensive and intensive), and should result in a `State Block` with zero degrees of freedom if all the state variables are fixed.\n",
+ "The first step in defining a `State Block` is to create the “state variables” which will be used to define the “state” of the material at any given point. The concept of a “state variable” in IDAES is much the same as the concept in thermodynamics, with the exception that we include extensive flow information in the state definition in IDAES. In short, the “state variables” should be sufficient to fully define the state of the material (both extensive and intensive), and should result in a `State Block` with zero degrees of freedom if all the state variables are fixed.\n",
"\n",
"For this example, our state variables will be:\n",
"\n",
@@ -614,7 +614,7 @@
"2. by using an `Expression`, or,\n",
"3. by using a `Reference`.\n",
"\n",
- "The different between the first two options is that an `Expression` does not appear in the problem passed to the solver \u2013 the `Expression` can be evaluated by the user and included in constraints in the same way as a variable, but when the problem is passed to the solver the `Expression` object is substituted for the expression it represents wherever it appears in the model. This means that there are fewer variables and constraints in the problem the solver sees, but that the constraints that do appear are more complex. There is no simple answer to which approach is best, and different applications may see better results with one form or the other. The third option, using a `Reference` is for cases where a property already exists elsewhere in the model, and we just want to create a local copy of the same object. In terms of properties, this most often occurs with fixed quantities which are declared in the Physical Parameter Block such as molecular weights. For the purposes of this example, we will demonstrate all of these approaches. \n",
+ "The different between the first two options is that an `Expression` does not appear in the problem passed to the solver – the `Expression` can be evaluated by the user and included in constraints in the same way as a variable, but when the problem is passed to the solver the `Expression` object is substituted for the expression it represents wherever it appears in the model. This means that there are fewer variables and constraints in the problem the solver sees, but that the constraints that do appear are more complex. There is no simple answer to which approach is best, and different applications may see better results with one form or the other. The third option, using a `Reference` is for cases where a property already exists elsewhere in the model, and we just want to create a local copy of the same object. In terms of properties, this most often occurs with fixed quantities which are declared in the Physical Parameter Block such as molecular weights. For the purposes of this example, we will demonstrate all of these approaches. \n",
"\n",
"You may recall from the initial problem statement that we have three properties of interest in this example:\n",
"\n",
@@ -658,7 +658,7 @@
"where $x_j$ is the mole fraction of component $j$. Recall that for this example we are using the following correlation for the component specific enthalpies.\n",
"\n",
"\\begin{equation*}\n",
- "h_j \u2013 h_{j, ref}= A_j \\times (T-T_{ref}) + \\frac{B_j}{2}\\times (T^2-T_{ref}^2) + \\frac{C_j}{3}\\times (T^3-T_{ref}^3) + \\frac{D_j}{4}\\times (T^4-T_{ref}^4)\n",
+ "h_j – h_{j, ref}= A_j \\times (T-T_{ref}) + \\frac{B_j}{2}\\times (T^2-T_{ref}^2) + \\frac{C_j}{3}\\times (T^3-T_{ref}^3) + \\frac{D_j}{4}\\times (T^4-T_{ref}^4)\n",
"\\end{equation*}\n",
"\n",
"For the specific enthalpy, we will create a Pyomo `Expression` rather than a `Var` and `Constraint`. In practice, this is much like creating a `Constraint`. However, rather than returning an equality between two expressions, an `Expression` requires a single numerical expression that can be used to compute the quantity of interest.\n",
@@ -736,16 +736,16 @@
"\n",
"### Writing the Initialization Routine\n",
"\n",
- "For initializing State Blocks, the first step is to get our model to a state where it has no degrees of freedom. As mentioned earlier, fixing all of the state variables should be sufficient to fully define the state of the material \u2013 i.e. no degrees of freedom. Additionally, we want to initialize our State Block at a set of conditions that are good initial guesses for the final state of the model once it is finally solved. Of course, the State Block has no way of knowing what these initial values should be, so we depend on the unit model (or the end-user) to provide us with a set of initial values to use \u2013 this is done through a `dict` which we generally call `state_args` where the keys are the names of the state variables and the values are the initial guesses.\n",
+ "For initializing State Blocks, the first step is to get our model to a state where it has no degrees of freedom. As mentioned earlier, fixing all of the state variables should be sufficient to fully define the state of the material – i.e. no degrees of freedom. Additionally, we want to initialize our State Block at a set of conditions that are good initial guesses for the final state of the model once it is finally solved. Of course, the State Block has no way of knowing what these initial values should be, so we depend on the unit model (or the end-user) to provide us with a set of initial values to use – this is done through a `dict` which we generally call `state_args` where the keys are the names of the state variables and the values are the initial guesses.\n",
"\n",
- "Before we start fixing the state variables, there is the possibility that all the state variables have already been fixed (e.g. by a the unit model during its own initialization routine). To allow us to save some time, we include a `state_vars_fixed` argument in our State Block initialization methods that lets the unit model tell us if the state variables are already fixed \u2013 if this is `True` then we know we can skip the step of checking the state variables ourselves. If `state_vars_fixed is False` however, then we need to go and fix all the state variables as part of our initialization routine. To save us the effort of having to code all of this ourselves, the IDAES toolkit contains a utility method named `fix_state_vars` (which we imported earlier), which takes the `state_args` `dict` and then iterates through all the state variables as defined by the State Block (using the `dict` we declared earlier in the `return_state_var_dict` sub-method). This method iterates through all the defined state variables and does the following:\n",
+ "Before we start fixing the state variables, there is the possibility that all the state variables have already been fixed (e.g. by a the unit model during its own initialization routine). To allow us to save some time, we include a `state_vars_fixed` argument in our State Block initialization methods that lets the unit model tell us if the state variables are already fixed – if this is `True` then we know we can skip the step of checking the state variables ourselves. If `state_vars_fixed is False` however, then we need to go and fix all the state variables as part of our initialization routine. To save us the effort of having to code all of this ourselves, the IDAES toolkit contains a utility method named `fix_state_vars` (which we imported earlier), which takes the `state_args` `dict` and then iterates through all the state variables as defined by the State Block (using the `dict` we declared earlier in the `return_state_var_dict` sub-method). This method iterates through all the defined state variables and does the following:\n",
"\n",
"1. If the variable is already fixed, it records this and does nothing. If a variable is already fixed, we assume it was fixed for a reason and that we should not change its value.\n",
"2. If the variable is not fixed, this is recorded and the method then checks the `state_args` dict for an initial guess for the variable. If a value is found, the variable is fixed to this value; otherwise, the variable is fixed to its
current value.\n",
"\n",
"Finally, the `fix_state_vars` method returns a `dict` that records which variables were fixed by the method, so that we can later reverse these changes. In the example below, we refer to this `dict` as `flags`.\n",
"\n",
- "At this point, all the state variables should now be fixed, but once again we have a small catch \u2013 if we fix all the state variables then we have a situation similar to the inlet of a unit where we cannot write a constraint on the sum of mole fractions and still solve the model. Thus we need to deactivate this constraint
if it exists (remembering that this constraint will not exist in all State Blocks). We know that this constraint will only exist if `defined_state is False`, so we start by writing an `IF` statement to check for this and then use the Pyomo `deactivate()` method to deactivate the constraint (remembering that we will need to reactivate it later).\n",
+ "At this point, all the state variables should now be fixed, but once again we have a small catch – if we fix all the state variables then we have a situation similar to the inlet of a unit where we cannot write a constraint on the sum of mole fractions and still solve the model. Thus we need to deactivate this constraint
if it exists (remembering that this constraint will not exist in all State Blocks). We know that this constraint will only exist if `defined_state is False`, so we start by writing an `IF` statement to check for this and then use the Pyomo `deactivate()` method to deactivate the constraint (remembering that we will need to reactivate it later).\n",
"\n",
"Before we move on however, it is probably a good idea to check the degrees of freedom to be sure that they are zero (as expected). There are a number of ways things could go wrong (e.g., the unit model said the state variables were fixed when not all of them were, or we missed a constraint we need to deactivate), so a quick check now might save someone a lot of pain in the future. We can use the IDAES `degrees_of_freedom` method to check the degrees of freedom of our State Block, and if this is not zero raise an `Exception` to let the user know something went wrong."
]
@@ -788,7 +788,7 @@
"\n",
"Before we call the solver, we first need to make sure there is actually something to solve; depending on how the State Block is written (e.g. build-on-demand properties and use of `Expressions`), it is sometimes possible that there are actually no `Constraints` to be solved in the model. If we try to send a problem like that to a solver, we will likely get back an error message which is not what we want to see. Whilst we know that our State Block will always contain at least one constraint (for mixture density), we will add a check here anyway to show how it is done. First ,we create a counter to keep track of the number of unfixed variables in the system, `free_vars`. Then we iterate over all the elements of the `blk` (the `IndexedStateBlock`) and check how many free variables are in each. We use the `number_unfixed_variables()` method from the `idaes.core.util.model_statistics` module to do this, and add the result `free_vars` for each element. If the final value of `free_vars` is not zero, then we know there is something to solve for and we can proceed to call a solver; otherwise we know that we can skip this step.\n",
"\n",
- "In order to solve the entire `IndexedStateBlock`, we need to do things slightly differently than normal. The standard Pyomo `SolverFactory` cannot be applied to indexed blocks, so instead we use the IDAES `solve_indexed_block` method (imported from `idaes.core.initialization`) which puts a wrapper around the indexed block so that we can use Pyomo\u2019s solver interface. In order to use this method, we need to provide a Pyomo `SolverFactory` object (called `solver` here, which also includes any attached solver options) along with the `blk` we wish to solve and where to send the solver results (the `tee` argument). Additionally, we want the user to have the ability to control the output from the solver through the IDAES logger interface, which we do by wrapping the solver call with the following line of code:\n",
+ "In order to solve the entire `IndexedStateBlock`, we need to do things slightly differently than normal. The standard Pyomo `SolverFactory` cannot be applied to indexed blocks, so instead we use the IDAES `solve_indexed_block` method (imported from `idaes.core.initialization`) which puts a wrapper around the indexed block so that we can use Pyomo’s solver interface. In order to use this method, we need to provide a Pyomo `SolverFactory` object (called `solver` here, which also includes any attached solver options) along with the `blk` we wish to solve and where to send the solver results (the `tee` argument). Additionally, we want the user to have the ability to control the output from the solver through the IDAES logger interface, which we do by wrapping the solver call with the following line of code:\n",
"\n",
"```\n",
"with idaeslog.solver_log(solve_log, idaeslog.DEBUG) as slc:\n",
@@ -796,7 +796,7 @@
"\n",
"where `idaeslog` is an instance of the IDAES logger. Note that we send the solver output to this logger by setting `tee=slc`. In this way, all the output from the solver is passed into the logger allowing users to easily control the output level without needing to send additional arguments to the initialization methods.\n",
"\n",
- "If all goes well, the solver will successfully initialize our model and we can move on. However, sometimes the solver will fail catastrophically, in which case we need to make sure that our initialization routine can attempt to recover. In order to do this, we wrap the solver call within a Python `try/except` statement. This way, if the solver fails badly and returns an `Exception`, we can capture this and decide how to process \u2013 otherwise the execution of our model would terminate with the exception from the solver. In the case we encounter an `Exception` here, we will record `results=None` and try to continue with initializing our model in the hope that we can recover.\n",
+ "If all goes well, the solver will successfully initialize our model and we can move on. However, sometimes the solver will fail catastrophically, in which case we need to make sure that our initialization routine can attempt to recover. In order to do this, we wrap the solver call within a Python `try/except` statement. This way, if the solver fails badly and returns an `Exception`, we can capture this and decide how to process – otherwise the execution of our model would terminate with the exception from the solver. In the case we encounter an `Exception` here, we will record `results=None` and try to continue with initializing our model in the hope that we can recover.\n",
"\n",
"Finally, it is useful to provide the user with some feedback on how the initialization is proceeding. In the last lines below, we send a message to the IDAES logger with a message saying that the initialization step has been completed and append the final solver status."
]
@@ -900,7 +900,7 @@
"As the name suggests, the `initialize` method is used to run the initialization routine for the State Block, and this is where we will use the `prepare_state`, `initialize_state` and `restore_state` methods we wrote previously. The `initialize` method requires the following arguments to be declared:\n",
"\n",
"* `blk`: this will be a pointer to an instance of the State Block to be initialized.\n",
- "* `state_args`: this is used to pass the \u2018dict\u2019 of initial guesses to the initialization routine. This should default to `None` if not provided. The `fix_state_vars` method will interpret a value of `None` as no guesses provided as use the current values instead.\n",
+ "* `state_args`: this is used to pass the ‘dict’ of initial guesses to the initialization routine. This should default to `None` if not provided. The `fix_state_vars` method will interpret a value of `None` as no guesses provided as use the current values instead.\n",
"* `solver`: this argument is used to allow tell the State Block to use a specific solver during initialization, and should be a string recognized by the Pyomo `SolverFactory`. We generally set this to `None` in order to signify that IDAES Should use the default solver (which is IPOPT).\n",
"* `optarg`: this argument is used to set any solver options the user desires. Again this is generally set to `None` to indicate that the default solver settings should be used.\n",
"* `state_vars_fixed`: argument to allow the unit model to inform the State Block that the state variables are already fixed. This should default to `False`.\n",
@@ -959,13 +959,13 @@
"source": [
"### The StateBlockData class\n",
"\n",
- "Finally, we can build the `StateBlockData` class, which we will call `HDAStateBlockData`. First, we use the `declare_process_block_class` decorator but this time we provide two arguments. The first argument is the name of the class that will be automatically constructed for us (`HDAStateBlock`) whilst the second argument is a reference to the class we wish to use as the base when building the `IndexedHDAStateBlock` class \u2013 i.e. the `_HDAStateBlock` class we just declared. Then, we declare our new `HDAStateBlockData` class and inherit from the IDAES `StateBlockData` base class.\n",
+ "Finally, we can build the `StateBlockData` class, which we will call `HDAStateBlockData`. First, we use the `declare_process_block_class` decorator but this time we provide two arguments. The first argument is the name of the class that will be automatically constructed for us (`HDAStateBlock`) whilst the second argument is a reference to the class we wish to use as the base when building the `IndexedHDAStateBlock` class – i.e. the `_HDAStateBlock` class we just declared. Then, we declare our new `HDAStateBlockData` class and inherit from the IDAES `StateBlockData` base class.\n",
"\n",
"As usual, the first thing we need to define in our new class is a `build` method, where we will provide the instructions for constructing our property model, and once again the first thing we should do is call `super().build()` to construct all the underlying components defined by the parent class. After this, we can call the methods we wrote earlier to construct the state variables and the add the calculations for the properties of interest.\n",
"\n",
- "However, if you recall from when we defined the properties metadata at the beginning of the example, we decided that the specific molar enthalpy of the mixture would be a \u201cbuild-on-demand\u201d property (i.e., we provided a specific method in the properties metadata rather than `None`). Thus, we do not want to call the method to construct the specific molar enthalpy as part of the `build` method, meaning that we only call the `add_state_variables`, `add_mole_fraction_constraint` and `add_molecular_weight_and_density` as in the `build` method.\n",
+ "However, if you recall from when we defined the properties metadata at the beginning of the example, we decided that the specific molar enthalpy of the mixture would be a “build-on-demand” property (i.e., we provided a specific method in the properties metadata rather than `None`). Thus, we do not want to call the method to construct the specific molar enthalpy as part of the `build` method, meaning that we only call the `add_state_variables`, `add_mole_fraction_constraint` and `add_molecular_weight_and_density` as in the `build` method.\n",
"\n",
- "To add the specific molar enthalpy calculation as a \u201cbuild-on-demand\u201d property, we instead declare a separate method with the name we provided in the properties metadata. Whenever the specific molar enthalpy is required by a unit model it will check to see if the property already exists, and if not it will look up the properties metadata and call the method listed there; i.e. `_enth_mol` in this case. Thus, we declare another method on our `HDAStateBlockData` class named `enth_mol` which takes only the class instance as an argument (`self`), and then call the `add_enth_mol` method we created earlier to construct the required `Expression`.\n",
+ "To add the specific molar enthalpy calculation as a “build-on-demand” property, we instead declare a separate method with the name we provided in the properties metadata. Whenever the specific molar enthalpy is required by a unit model it will check to see if the property already exists, and if not it will look up the properties metadata and call the method listed there; i.e. `_enth_mol` in this case. Thus, we declare another method on our `HDAStateBlockData` class named `enth_mol` which takes only the class instance as an argument (`self`), and then call the `add_enth_mol` method we created earlier to construct the required `Expression`.\n",
"\n",
"That is all we need to do in order to construct the variables and constraints we need for the property calculations. However, there are a number of other things we need to define in our State Block Data class. In order to provide much of the flexibility present in the IDAES modeling framework, we defer making decisions on much of the form of the overall model for as long as possible. However, these decisions need to be made at some point, and the State Block Data is where this finally occurs.\n",
"\n",
@@ -983,7 +983,7 @@
"* `default_material_balance_type` should return an instance of the IDAES `MaterialBalanceType` `Enum` (imported from `idaes.core`).\n",
"* `default_energy_balance_type` should return an instance of the IDAES `EnergyBalanceType` `Enum` (imported from `idaes.core`).\n",
"\n",
- "Finally, we need to specify the basis of the material flow terms (mass, mole or other). This is used to automatically convert between different bases as required (e.g. a user can define a custom mass transfer term on a molar basis whilst using a mass basis for the actual material balance). Note that automatic conversion only works for mass and molar basis; the \u201cother\u201d basis is used to indicate forms which cannot be easily converted (i.e., the modeler needs to handle this manually). To define the material flow term basis we define a final method named `get_material_flow_basis` which returns an instance of the IDAES `MaterialFlowBasis` `Enum` (again imported from `idaes.core`)."
+ "Finally, we need to specify the basis of the material flow terms (mass, mole or other). This is used to automatically convert between different bases as required (e.g. a user can define a custom mass transfer term on a molar basis whilst using a mass basis for the actual material balance). Note that automatic conversion only works for mass and molar basis; the “other” basis is used to indicate forms which cannot be easily converted (i.e., the modeler needs to handle this manually). To define the material flow term basis we define a final method named `get_material_flow_basis` which returns an instance of the IDAES `MaterialFlowBasis` `Enum` (again imported from `idaes.core`)."
]
},
{
@@ -1055,9 +1055,9 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "Next, we create `ConcreteModel` and a steady-state `FlowsheetBlock` to contain our example, ot which we attach an instance of our new `HDAPhysicalParameterBlock`.\n",
+ "Next, we create `ConcreteModel` and a steady-state `FlowsheetBlock` to contain our example, to which we attach an instance of our new `HDAPhysicalParameterBlock`.\n",
"\n",
- "We can then create an instance of the `HDAStateBlock` directly from the parameter block using the `build_state_block` method. This uses the reference to the State Block class that we attached ot the Physical Parameter Block earlier in the example to automatically create an instance of the correct class. Note that we index the State Block by the time domain, so that it looks like a typical state block in a flowsheet, and we set `defined_state = True` so that we can set values for all the component mole fractions later."
+ "We can then create an instance of the `HDAStateBlock` directly from the parameter block using the `build_state_block` method. This uses the reference to the State Block class that we attached to the Physical Parameter Block earlier in the example to automatically create an instance of the correct class. Note that we index the State Block by the time domain, so that it looks like a typical state block in a flowsheet, and we set `defined_state = True` so that we can set values for all the component mole fractions later."
]
},
{
@@ -1079,7 +1079,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "We now have an instance of our new State Block in our flowsheet, so let\u2019s display it and see what it contains."
+ "We now have an instance of our new State Block in our flowsheet, so let’s display it and see what it contains."
]
},
{
@@ -1095,7 +1095,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "We can see that our State Block contains a single point in time, which in turn contains the five variables. These are our four state variables (molar flow rate, component mole fraction, temperature and pressure) as well as the mixture density. We also have a single constraint, which is the ideal gas equation used to calculate density. Note that we don\u2019t see the component molecular weights as they are `Params` (`References` take on the appearance of the component being referenced) or the molar enthalpy as it is an `Expression`, not a variable (plus it hasn\u2019t been constructed yet as we haven\u2019t asked for it).\n",
+ "We can see that our State Block contains a single point in time, which in turn contains the five variables. These are our four state variables (molar flow rate, component mole fraction, temperature and pressure) as well as the mixture density. We also have a single constraint, which is the ideal gas equation used to calculate density. Note that we don’t see the component molecular weights as they are `Params` (`References` take on the appearance of the component being referenced) or the molar enthalpy as it is an `Expression`, not a variable (plus it hasn’t been constructed yet as we haven’t asked for it).\n",
"\n",
"Next, let us check the degrees of freedom in our State Block."
]
@@ -1115,7 +1115,7 @@
"source": [
"This is unexpected: the `degrees_of_freedom` method is saying there are only 2 degrees of freedom in our State Block, but there are 8 state variables.\n",
"\n",
- "However, if we think about the constraints we have written, we are only actually using 2 of the state variables in any constraint (temperature and pressure appear in the ideal gas equation). The molar flowrate and component mole fractions are not actually used anywhere in our model, so they have been excluded from the degrees of freedom calculation. In Pyomo terminology, these variables are \u201cStale\u201d, and they will not be sent to the solver when it is called. Thus, the two degrees of freedom is in fact correct.\n",
+ "However, if we think about the constraints we have written, we are only actually using 2 of the state variables in any constraint (temperature and pressure appear in the ideal gas equation). The molar flowrate and component mole fractions are not actually used anywhere in our model, so they have been excluded from the degrees of freedom calculation. In Pyomo terminology, these variables are “Stale”, and they will not be sent to the solver when it is called. Thus, the two degrees of freedom is in fact correct.\n",
"\n",
"Note that this is only the case because our property package is so simple. Also, the specific enthalpy calculation depends on the component mole fractions, so whilst we could solve the State Block by only specifying temperature and pressure, the value of the specific molar enthalpy would be meaningless.\n",
"\n",
@@ -1142,7 +1142,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "Now that we have fixed the values for all the state variables, we would expect that the degrees of freedom should be zero (even though we fixed all 8 variables, only temperature and pressure actually contribute to the degrees of freedom). Let\u2019s check this to be sure."
+ "Now that we have fixed the values for all the state variables, we would expect that the degrees of freedom should be zero (even though we fixed all 8 variables, only temperature and pressure actually contribute to the degrees of freedom). Let’s check this to be sure."
]
},
{
@@ -1364,4 +1364,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/properties/parameter_estimation_pr.ipynb b/idaes_examples/notebooks/docs/properties/parameter_estimation_pr.ipynb
index cbbd307e..1546704a 100644
--- a/idaes_examples/notebooks/docs/properties/parameter_estimation_pr.ipynb
+++ b/idaes_examples/notebooks/docs/properties/parameter_estimation_pr.ipynb
@@ -35,7 +35,7 @@
"Updated: 2023-06-01 \n",
"## 1. Introduction\n",
"\n",
- "This Jupyter Notebook estimates binary interaction parameters for a CO$_2$-Ionic liquid property package. A property package has been created for CO$_2$-[bmim][PF6]. We will utilize Pyomo's `parmest` tool in conjuction with IDAES models for parameter estimation. We demonstrate these tools by estimating the parameters associated with the Peng-Robinson property model for a benzene-toluene mixture. The Peng-Robinson EOS the binary interaction parameter (kappa_ij). When estimating parameters associated with the property package, IDAES provides the flexibility of doing the parameter estimation by just using the state block or by using a unit model with a specified property package. This module will demonstrate parameter estimation by using the flash unit model with a Modular Property Package.\n",
+ "This Jupyter Notebook estimates binary interaction parameters for a CO$_2$-Ionic liquid property package. A property package has been created for CO$_2$-[bmim][PF6]. We will utilize Pyomo's `parmest` tool in conjunction with IDAES models for parameter estimation. We demonstrate these tools by estimating the parameters associated with the Peng-Robinson property model for a benzene-toluene mixture. The Peng-Robinson EOS the binary interaction parameter (kappa_ij). When estimating parameters associated with the property package, IDAES provides the flexibility of doing the parameter estimation by just using the state block or by using a unit model with a specified property package. This module will demonstrate parameter estimation by using the flash unit model with a Modular Property Package.\n",
"\n",
"### 1.1 Tutorial objectives\n",
"\n",
diff --git a/idaes_examples/notebooks/docs/properties/parameter_estimation_pr_doc.ipynb b/idaes_examples/notebooks/docs/properties/parameter_estimation_pr_doc.ipynb
index 545f8154..ea87d247 100644
--- a/idaes_examples/notebooks/docs/properties/parameter_estimation_pr_doc.ipynb
+++ b/idaes_examples/notebooks/docs/properties/parameter_estimation_pr_doc.ipynb
@@ -35,7 +35,7 @@
"Updated: 2023-06-01 \n",
"## 1. Introduction\n",
"\n",
- "This Jupyter Notebook estimates binary interaction parameters for a CO$_2$-Ionic liquid property package. A property package has been created for CO$_2$-[bmim][PF6]. We will utilize Pyomo's `parmest` tool in conjuction with IDAES models for parameter estimation. We demonstrate these tools by estimating the parameters associated with the Peng-Robinson property model for a benzene-toluene mixture. The Peng-Robinson EOS the binary interaction parameter (kappa_ij). When estimating parameters associated with the property package, IDAES provides the flexibility of doing the parameter estimation by just using the state block or by using a unit model with a specified property package. This module will demonstrate parameter estimation by using the flash unit model with a Modular Property Package.\n",
+ "This Jupyter Notebook estimates binary interaction parameters for a CO$_2$-Ionic liquid property package. A property package has been created for CO$_2$-[bmim][PF6]. We will utilize Pyomo's `parmest` tool in conjunction with IDAES models for parameter estimation. We demonstrate these tools by estimating the parameters associated with the Peng-Robinson property model for a benzene-toluene mixture. The Peng-Robinson EOS the binary interaction parameter (kappa_ij). When estimating parameters associated with the property package, IDAES provides the flexibility of doing the parameter estimation by just using the state block or by using a unit model with a specified property package. This module will demonstrate parameter estimation by using the flash unit model with a Modular Property Package.\n",
"\n",
"### 1.1 Tutorial objectives\n",
"\n",
@@ -1594,4 +1594,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/properties/parameter_estimation_pr_test.ipynb b/idaes_examples/notebooks/docs/properties/parameter_estimation_pr_test.ipynb
index f6c17e61..4d620a5a 100644
--- a/idaes_examples/notebooks/docs/properties/parameter_estimation_pr_test.ipynb
+++ b/idaes_examples/notebooks/docs/properties/parameter_estimation_pr_test.ipynb
@@ -35,7 +35,7 @@
"Updated: 2023-06-01 \n",
"## 1. Introduction\n",
"\n",
- "This Jupyter Notebook estimates binary interaction parameters for a CO$_2$-Ionic liquid property package. A property package has been created for CO$_2$-[bmim][PF6]. We will utilize Pyomo's `parmest` tool in conjuction with IDAES models for parameter estimation. We demonstrate these tools by estimating the parameters associated with the Peng-Robinson property model for a benzene-toluene mixture. The Peng-Robinson EOS the binary interaction parameter (kappa_ij). When estimating parameters associated with the property package, IDAES provides the flexibility of doing the parameter estimation by just using the state block or by using a unit model with a specified property package. This module will demonstrate parameter estimation by using the flash unit model with a Modular Property Package.\n",
+ "This Jupyter Notebook estimates binary interaction parameters for a CO$_2$-Ionic liquid property package. A property package has been created for CO$_2$-[bmim][PF6]. We will utilize Pyomo's `parmest` tool in conjunction with IDAES models for parameter estimation. We demonstrate these tools by estimating the parameters associated with the Peng-Robinson property model for a benzene-toluene mixture. The Peng-Robinson EOS the binary interaction parameter (kappa_ij). When estimating parameters associated with the property package, IDAES provides the flexibility of doing the parameter estimation by just using the state block or by using a unit model with a specified property package. This module will demonstrate parameter estimation by using the flash unit model with a Modular Property Package.\n",
"\n",
"### 1.1 Tutorial objectives\n",
"\n",
@@ -352,4 +352,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/properties/parameter_estimation_pr_usr.ipynb b/idaes_examples/notebooks/docs/properties/parameter_estimation_pr_usr.ipynb
index f6c17e61..4d620a5a 100644
--- a/idaes_examples/notebooks/docs/properties/parameter_estimation_pr_usr.ipynb
+++ b/idaes_examples/notebooks/docs/properties/parameter_estimation_pr_usr.ipynb
@@ -35,7 +35,7 @@
"Updated: 2023-06-01 \n",
"## 1. Introduction\n",
"\n",
- "This Jupyter Notebook estimates binary interaction parameters for a CO$_2$-Ionic liquid property package. A property package has been created for CO$_2$-[bmim][PF6]. We will utilize Pyomo's `parmest` tool in conjuction with IDAES models for parameter estimation. We demonstrate these tools by estimating the parameters associated with the Peng-Robinson property model for a benzene-toluene mixture. The Peng-Robinson EOS the binary interaction parameter (kappa_ij). When estimating parameters associated with the property package, IDAES provides the flexibility of doing the parameter estimation by just using the state block or by using a unit model with a specified property package. This module will demonstrate parameter estimation by using the flash unit model with a Modular Property Package.\n",
+ "This Jupyter Notebook estimates binary interaction parameters for a CO$_2$-Ionic liquid property package. A property package has been created for CO$_2$-[bmim][PF6]. We will utilize Pyomo's `parmest` tool in conjunction with IDAES models for parameter estimation. We demonstrate these tools by estimating the parameters associated with the Peng-Robinson property model for a benzene-toluene mixture. The Peng-Robinson EOS the binary interaction parameter (kappa_ij). When estimating parameters associated with the property package, IDAES provides the flexibility of doing the parameter estimation by just using the state block or by using a unit model with a specified property package. This module will demonstrate parameter estimation by using the flash unit model with a Modular Property Package.\n",
"\n",
"### 1.1 Tutorial objectives\n",
"\n",
@@ -352,4 +352,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/surrogates/best_practices_optimization.ipynb b/idaes_examples/notebooks/docs/surrogates/best_practices_optimization.ipynb
index d1d8c2b8..a2b493ba 100644
--- a/idaes_examples/notebooks/docs/surrogates/best_practices_optimization.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/best_practices_optimization.ipynb
@@ -271,7 +271,7 @@
"source": [
"## 4.2 Model Size/Form Comparison\n",
"\n",
- "As mentioned above, as part of best practices the IDAES ML/AI demonstration includes the analysis of model/solver statistics and performance to determine the best surrogate model, including model size, model form, model trainer, etc. This section provides the rigorous analysis of solver performance comparing differnt surrogate models (ALAMO, PySMO polynomial, PysMO RBF, and PySMO Kriging).\n",
+ "As mentioned above, as part of best practices the IDAES ML/AI demonstration includes the analysis of model/solver statistics and performance to determine the best surrogate model, including model size, model form, model trainer, etc. This section provides the rigorous analysis of solver performance comparing different surrogate models (ALAMO, PySMO polynomial, PysMO RBF, and PySMO Kriging).\n",
"\n",
"To obtain the results, we run the flowsheet for ten different simulation cases for each surrogate model type. Since the simulation cases are obtained from the training data set we can compare model performance (absolute error of measurement vs predicted output values)."
]
@@ -297,7 +297,7 @@
"# selecting columns that correspond to Input Variables\n",
"inputs = np.array(case_data.iloc[:, :2])\n",
"\n",
- "# selecting columns that correspod to Output Variables\n",
+ "# selecting columns that correspond to Output Variables\n",
"cols = [\"Steam_Flow\", \"Reformer_Duty\", \"C2H6\", \"CH4\", \"H2\", \"O2\"]\n",
"outputs = np.array(case_data[cols])\n",
"\n",
@@ -635,4 +635,4 @@
},
"nbformat": 4,
"nbformat_minor": 4
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/surrogates/best_practices_optimization_doc.ipynb b/idaes_examples/notebooks/docs/surrogates/best_practices_optimization_doc.ipynb
index 109e07bd..939c494d 100644
--- a/idaes_examples/notebooks/docs/surrogates/best_practices_optimization_doc.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/best_practices_optimization_doc.ipynb
@@ -304,7 +304,7 @@
"source": [
"## 4.2 Model Size/Form Comparison\n",
"\n",
- "As mentioned above, as part of best practices the IDAES ML/AI demonstration includes the analysis of model/solver statistics and performance to determine the best surrogate model, including model size, model form, model trainer, etc. This section provides the rigorous analysis of solver performance comparing differnt surrogate models (ALAMO, PySMO polynomial, PysMO RBF, and PySMO Kriging).\n",
+ "As mentioned above, as part of best practices the IDAES ML/AI demonstration includes the analysis of model/solver statistics and performance to determine the best surrogate model, including model size, model form, model trainer, etc. This section provides the rigorous analysis of solver performance comparing different surrogate models (ALAMO, PySMO polynomial, PysMO RBF, and PySMO Kriging).\n",
"\n",
"To obtain the results, we run the flowsheet for ten different simulation cases for each surrogate model type. Since the simulation cases are obtained from the training data set we can compare model performance (absolute error of measurement vs predicted output values)."
]
@@ -2647,7 +2647,7 @@
"# selecting columns that correspond to Input Variables\n",
"inputs = np.array(case_data.iloc[:, :2])\n",
"\n",
- "# selecting columns that correspod to Output Variables\n",
+ "# selecting columns that correspond to Output Variables\n",
"cols = [\"Steam_Flow\", \"Reformer_Duty\", \"C2H6\", \"CH4\", \"H2\", \"O2\"]\n",
"outputs = np.array(case_data[cols])\n",
"\n",
@@ -3494,4 +3494,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/surrogates/best_practices_optimization_test.ipynb b/idaes_examples/notebooks/docs/surrogates/best_practices_optimization_test.ipynb
index 2ab637d7..90a84df6 100644
--- a/idaes_examples/notebooks/docs/surrogates/best_practices_optimization_test.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/best_practices_optimization_test.ipynb
@@ -271,7 +271,7 @@
"source": [
"## 4.2 Model Size/Form Comparison\n",
"\n",
- "As mentioned above, as part of best practices the IDAES ML/AI demonstration includes the analysis of model/solver statistics and performance to determine the best surrogate model, including model size, model form, model trainer, etc. This section provides the rigorous analysis of solver performance comparing differnt surrogate models (ALAMO, PySMO polynomial, PysMO RBF, and PySMO Kriging).\n",
+ "As mentioned above, as part of best practices the IDAES ML/AI demonstration includes the analysis of model/solver statistics and performance to determine the best surrogate model, including model size, model form, model trainer, etc. This section provides the rigorous analysis of solver performance comparing different surrogate models (ALAMO, PySMO polynomial, PysMO RBF, and PySMO Kriging).\n",
"\n",
"To obtain the results, we run the flowsheet for ten different simulation cases for each surrogate model type. Since the simulation cases are obtained from the training data set we can compare model performance (absolute error of measurement vs predicted output values)."
]
@@ -297,7 +297,7 @@
"# selecting columns that correspond to Input Variables\n",
"inputs = np.array(case_data.iloc[:, :2])\n",
"\n",
- "# selecting columns that correspod to Output Variables\n",
+ "# selecting columns that correspond to Output Variables\n",
"cols = [\"Steam_Flow\", \"Reformer_Duty\", \"C2H6\", \"CH4\", \"H2\", \"O2\"]\n",
"outputs = np.array(case_data[cols])\n",
"\n",
@@ -635,4 +635,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/surrogates/best_practices_optimization_usr.ipynb b/idaes_examples/notebooks/docs/surrogates/best_practices_optimization_usr.ipynb
index c83e4407..174e9648 100644
--- a/idaes_examples/notebooks/docs/surrogates/best_practices_optimization_usr.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/best_practices_optimization_usr.ipynb
@@ -271,7 +271,7 @@
"source": [
"## 4.2 Model Size/Form Comparison\n",
"\n",
- "As mentioned above, as part of best practices the IDAES ML/AI demonstration includes the analysis of model/solver statistics and performance to determine the best surrogate model, including model size, model form, model trainer, etc. This section provides the rigorous analysis of solver performance comparing differnt surrogate models (ALAMO, PySMO polynomial, PysMO RBF, and PySMO Kriging).\n",
+ "As mentioned above, as part of best practices the IDAES ML/AI demonstration includes the analysis of model/solver statistics and performance to determine the best surrogate model, including model size, model form, model trainer, etc. This section provides the rigorous analysis of solver performance comparing different surrogate models (ALAMO, PySMO polynomial, PysMO RBF, and PySMO Kriging).\n",
"\n",
"To obtain the results, we run the flowsheet for ten different simulation cases for each surrogate model type. Since the simulation cases are obtained from the training data set we can compare model performance (absolute error of measurement vs predicted output values)."
]
@@ -297,7 +297,7 @@
"# selecting columns that correspond to Input Variables\n",
"inputs = np.array(case_data.iloc[:, :2])\n",
"\n",
- "# selecting columns that correspod to Output Variables\n",
+ "# selecting columns that correspond to Output Variables\n",
"cols = [\"Steam_Flow\", \"Reformer_Duty\", \"C2H6\", \"CH4\", \"H2\", \"O2\"]\n",
"outputs = np.array(case_data[cols])\n",
"\n",
@@ -635,4 +635,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/surrogates/pysmo/pysmo_basics.ipynb b/idaes_examples/notebooks/docs/surrogates/pysmo/pysmo_basics.ipynb
index 22fb82db..60c8f350 100644
--- a/idaes_examples/notebooks/docs/surrogates/pysmo/pysmo_basics.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/pysmo/pysmo_basics.ipynb
@@ -298,7 +298,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "For this example, let us consider a 4th order polynomial with interaction terms. We will split the data 80/20 betweeen training and cross-validation."
+ "For this example, let us consider a 4th order polynomial with interaction terms. We will split the data 80/20 between training and cross-validation."
]
},
{
diff --git a/idaes_examples/notebooks/docs/surrogates/pysmo/pysmo_basics_doc.ipynb b/idaes_examples/notebooks/docs/surrogates/pysmo/pysmo_basics_doc.ipynb
index ecf3aa8a..7a3c6798 100644
--- a/idaes_examples/notebooks/docs/surrogates/pysmo/pysmo_basics_doc.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/pysmo/pysmo_basics_doc.ipynb
@@ -426,7 +426,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "For this example, let us consider a 4th order polynomial with interaction terms. We will split the data 80/20 betweeen training and cross-validation."
+ "For this example, let us consider a 4th order polynomial with interaction terms. We will split the data 80/20 between training and cross-validation."
]
},
{
@@ -1801,4 +1801,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/surrogates/pysmo/pysmo_basics_test.ipynb b/idaes_examples/notebooks/docs/surrogates/pysmo/pysmo_basics_test.ipynb
index 02d2456f..16ec6887 100644
--- a/idaes_examples/notebooks/docs/surrogates/pysmo/pysmo_basics_test.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/pysmo/pysmo_basics_test.ipynb
@@ -298,7 +298,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "For this example, let us consider a 4th order polynomial with interaction terms. We will split the data 80/20 betweeen training and cross-validation."
+ "For this example, let us consider a 4th order polynomial with interaction terms. We will split the data 80/20 between training and cross-validation."
]
},
{
@@ -864,4 +864,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/surrogates/pysmo/pysmo_basics_usr.ipynb b/idaes_examples/notebooks/docs/surrogates/pysmo/pysmo_basics_usr.ipynb
index 02d2456f..16ec6887 100644
--- a/idaes_examples/notebooks/docs/surrogates/pysmo/pysmo_basics_usr.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/pysmo/pysmo_basics_usr.ipynb
@@ -298,7 +298,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "For this example, let us consider a 4th order polynomial with interaction terms. We will split the data 80/20 betweeen training and cross-validation."
+ "For this example, let us consider a 4th order polynomial with interaction terms. We will split the data 80/20 between training and cross-validation."
]
},
{
@@ -864,4 +864,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/alamo/alamo_training.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/alamo/alamo_training.ipynb
index fbdf0fd8..697c764f 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/alamo/alamo_training.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/alamo/alamo_training.ipynb
@@ -42,7 +42,7 @@
"### 1.1 Need for ML Surrogate\n",
"\n",
"The properties predicted by the surrogate are enthalpy and entropy of the S-CO2 based on the \n",
- "pressure and temperature of the system. The analytical equation of getting the enthalpy and entropy from pressure and temperature are in the differential form and would make the problem a DAE system. To counter this problem and keep the problem algebric, we will use the surrogates and relate enthalpy and entropy with the pressure and temperature as an algebric equation.\n",
+ "pressure and temperature of the system. The analytical equation of getting the enthalpy and entropy from pressure and temperature are in the differential form and would make the problem a DAE system. To counter this problem and keep the problem algebraic, we will use the surrogates and relate enthalpy and entropy with the pressure and temperature as an algebraic equation.\n",
"\n",
"### 1.2 Supercritical CO2 cycle process\n",
"\n",
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/alamo/alamo_training_doc.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/alamo/alamo_training_doc.ipynb
index 8f73584e..952f75a1 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/alamo/alamo_training_doc.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/alamo/alamo_training_doc.ipynb
@@ -42,7 +42,7 @@
"### 1.1 Need for ML Surrogate\n",
"\n",
"The properties predicted by the surrogate are enthalpy and entropy of the S-CO2 based on the \n",
- "pressure and temperature of the system. The analytical equation of getting the enthalpy and entropy from pressure and temperature are in the differential form and would make the problem a DAE system. To counter this problem and keep the problem algebric, we will use the surrogates and relate enthalpy and entropy with the pressure and temperature as an algebric equation.\n",
+ "pressure and temperature of the system. The analytical equation of getting the enthalpy and entropy from pressure and temperature are in the differential form and would make the problem a DAE system. To counter this problem and keep the problem algebraic, we will use the surrogates and relate enthalpy and entropy with the pressure and temperature as an algebraic equation.\n",
"\n",
"### 1.2 Supercritical CO2 cycle process\n",
"\n",
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/alamo/alamo_training_test.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/alamo/alamo_training_test.ipynb
index 554a9781..c439178b 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/alamo/alamo_training_test.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/alamo/alamo_training_test.ipynb
@@ -42,7 +42,7 @@
"### 1.1 Need for ML Surrogate\n",
"\n",
"The properties predicted by the surrogate are enthalpy and entropy of the S-CO2 based on the \n",
- "pressure and temperature of the system. The analytical equation of getting the enthalpy and entropy from pressure and temperature are in the differential form and would make the problem a DAE system. To counter this problem and keep the problem algebric, we will use the surrogates and relate enthalpy and entropy with the pressure and temperature as an algebric equation.\n",
+ "pressure and temperature of the system. The analytical equation of getting the enthalpy and entropy from pressure and temperature are in the differential form and would make the problem a DAE system. To counter this problem and keep the problem algebraic, we will use the surrogates and relate enthalpy and entropy with the pressure and temperature as an algebraic equation.\n",
"\n",
"### 1.2 Supercritical CO2 cycle process\n",
"\n",
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/alamo/alamo_training_usr.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/alamo/alamo_training_usr.ipynb
index 06bef3c4..f7081df1 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/alamo/alamo_training_usr.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/alamo/alamo_training_usr.ipynb
@@ -42,7 +42,7 @@
"### 1.1 Need for ML Surrogate\n",
"\n",
"The properties predicted by the surrogate are enthalpy and entropy of the S-CO2 based on the \n",
- "pressure and temperature of the system. The analytical equation of getting the enthalpy and entropy from pressure and temperature are in the differential form and would make the problem a DAE system. To counter this problem and keep the problem algebric, we will use the surrogates and relate enthalpy and entropy with the pressure and temperature as an algebric equation.\n",
+ "pressure and temperature of the system. The analytical equation of getting the enthalpy and entropy from pressure and temperature are in the differential form and would make the problem a DAE system. To counter this problem and keep the problem algebraic, we will use the surrogates and relate enthalpy and entropy with the pressure and temperature as an algebraic equation.\n",
"\n",
"### 1.2 Supercritical CO2 cycle process\n",
"\n",
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/alamo/flowsheet_optimization.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/alamo/flowsheet_optimization.ipynb
index 000282cd..2a53a5c7 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/alamo/flowsheet_optimization.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/alamo/flowsheet_optimization.ipynb
@@ -110,7 +110,7 @@
"source": [
"# 2. Constructing the flowsheet\n",
"\n",
- "To construct the flowsheet we need to define a ConcreteModel using pyomo and then add a FlowsheetBlock to the ConcreteModel. Here since we are focusing on the steady state process, we shall have the dynamic flag as False in the FlowsheetBlock. Next, we define the properties in the FlowsheetBlock that we imported from the properties.py file. Then start adding the unit models to the FlowsheetBlock with the suitable arguements, after which we connect them using Arcs as in the flowsheet above. \n",
+ "To construct the flowsheet we need to define a ConcreteModel using pyomo and then add a FlowsheetBlock to the ConcreteModel. Here since we are focusing on the steady state process, we shall have the dynamic flag as False in the FlowsheetBlock. Next, we define the properties in the FlowsheetBlock that we imported from the properties.py file. Then start adding the unit models to the FlowsheetBlock with the suitable arguments, after which we connect them using Arcs as in the flowsheet above. \n",
"\n",
"Once we have the connected flowsheet, we initialize individual unit models. Before initializing, we fix desired variables for the desired behavior of the unit model and then use `propagate_state` to pass on the state variables to next unit model in the flowsheet. After completely initializing the flowsheet, we convert the network to a mathematical form by using `network.expand_arcs` from the TransformationFactory and apply it on the flowsheet block. Then we call the solver and solve the flowsheet to calculate the total work in the process. "
]
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/alamo/flowsheet_optimization_doc.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/alamo/flowsheet_optimization_doc.ipynb
index 4be77c7a..dab89e00 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/alamo/flowsheet_optimization_doc.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/alamo/flowsheet_optimization_doc.ipynb
@@ -110,7 +110,7 @@
"source": [
"# 2. Constructing the flowsheet\n",
"\n",
- "To construct the flowsheet we need to define a ConcreteModel using pyomo and then add a FlowsheetBlock to the ConcreteModel. Here since we are focusing on the steady state process, we shall have the dynamic flag as False in the FlowsheetBlock. Next, we define the properties in the FlowsheetBlock that we imported from the properties.py file. Then start adding the unit models to the FlowsheetBlock with the suitable arguements, after which we connect them using Arcs as in the flowsheet above. \n",
+ "To construct the flowsheet we need to define a ConcreteModel using pyomo and then add a FlowsheetBlock to the ConcreteModel. Here since we are focusing on the steady state process, we shall have the dynamic flag as False in the FlowsheetBlock. Next, we define the properties in the FlowsheetBlock that we imported from the properties.py file. Then start adding the unit models to the FlowsheetBlock with the suitable arguments, after which we connect them using Arcs as in the flowsheet above. \n",
"\n",
"Once we have the connected flowsheet, we initialize individual unit models. Before initializing, we fix desired variables for the desired behavior of the unit model and then use `propagate_state` to pass on the state variables to next unit model in the flowsheet. After completely initializing the flowsheet, we convert the network to a mathematical form by using `network.expand_arcs` from the TransformationFactory and apply it on the flowsheet block. Then we call the solver and solve the flowsheet to calculate the total work in the process. "
]
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/alamo/flowsheet_optimization_test.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/alamo/flowsheet_optimization_test.ipynb
index 4be77c7a..dab89e00 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/alamo/flowsheet_optimization_test.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/alamo/flowsheet_optimization_test.ipynb
@@ -110,7 +110,7 @@
"source": [
"# 2. Constructing the flowsheet\n",
"\n",
- "To construct the flowsheet we need to define a ConcreteModel using pyomo and then add a FlowsheetBlock to the ConcreteModel. Here since we are focusing on the steady state process, we shall have the dynamic flag as False in the FlowsheetBlock. Next, we define the properties in the FlowsheetBlock that we imported from the properties.py file. Then start adding the unit models to the FlowsheetBlock with the suitable arguements, after which we connect them using Arcs as in the flowsheet above. \n",
+ "To construct the flowsheet we need to define a ConcreteModel using pyomo and then add a FlowsheetBlock to the ConcreteModel. Here since we are focusing on the steady state process, we shall have the dynamic flag as False in the FlowsheetBlock. Next, we define the properties in the FlowsheetBlock that we imported from the properties.py file. Then start adding the unit models to the FlowsheetBlock with the suitable arguments, after which we connect them using Arcs as in the flowsheet above. \n",
"\n",
"Once we have the connected flowsheet, we initialize individual unit models. Before initializing, we fix desired variables for the desired behavior of the unit model and then use `propagate_state` to pass on the state variables to next unit model in the flowsheet. After completely initializing the flowsheet, we convert the network to a mathematical form by using `network.expand_arcs` from the TransformationFactory and apply it on the flowsheet block. Then we call the solver and solve the flowsheet to calculate the total work in the process. "
]
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/alamo/flowsheet_optimization_usr.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/alamo/flowsheet_optimization_usr.ipynb
index 4be77c7a..dab89e00 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/alamo/flowsheet_optimization_usr.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/alamo/flowsheet_optimization_usr.ipynb
@@ -110,7 +110,7 @@
"source": [
"# 2. Constructing the flowsheet\n",
"\n",
- "To construct the flowsheet we need to define a ConcreteModel using pyomo and then add a FlowsheetBlock to the ConcreteModel. Here since we are focusing on the steady state process, we shall have the dynamic flag as False in the FlowsheetBlock. Next, we define the properties in the FlowsheetBlock that we imported from the properties.py file. Then start adding the unit models to the FlowsheetBlock with the suitable arguements, after which we connect them using Arcs as in the flowsheet above. \n",
+ "To construct the flowsheet we need to define a ConcreteModel using pyomo and then add a FlowsheetBlock to the ConcreteModel. Here since we are focusing on the steady state process, we shall have the dynamic flag as False in the FlowsheetBlock. Next, we define the properties in the FlowsheetBlock that we imported from the properties.py file. Then start adding the unit models to the FlowsheetBlock with the suitable arguments, after which we connect them using Arcs as in the flowsheet above. \n",
"\n",
"Once we have the connected flowsheet, we initialize individual unit models. Before initializing, we fix desired variables for the desired behavior of the unit model and then use `propagate_state` to pass on the state variables to next unit model in the flowsheet. After completely initializing the flowsheet, we convert the network to a mathematical form by using `network.expand_arcs` from the TransformationFactory and apply it on the flowsheet block. Then we call the solver and solve the flowsheet to calculate the total work in the process. "
]
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/alamo/properties.py b/idaes_examples/notebooks/docs/surrogates/sco2/alamo/properties.py
index 3b2f8bbb..dfb726d3 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/alamo/properties.py
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/alamo/properties.py
@@ -113,7 +113,7 @@ def initialize(blk, state_args=None, hold_state=False, outlvl=1,
* 0 = no output (default)
* 1 = return solver state for each step in routine
- * 2 = include solver output infomation (tee=True)
+ * 2 = include solver output information (tee=True)
state_vars_fixed: Flag to denote if state vars have already been
fixed.
- True - states have already been fixed by the
@@ -124,18 +124,18 @@ def initialize(blk, state_args=None, hold_state=False, outlvl=1,
- False - states have not been fixed. The state
block will deal with fixing/unfixing.
optarg : solver options dictionary object (default=None)
- solver : str indicating whcih solver to use during
+ solver : str indicating which 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).
- - True - states varaibles are not unfixed, and
+ - 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
- relase_state method
+ release_state method
Returns:
If hold_states is True, returns a dict containing flags for
@@ -195,7 +195,7 @@ def initialize(blk, state_args=None, hold_state=False, outlvl=1,
def release_state(blk, flags, outlvl=0):
'''
- Method to relase state variables fixed during initialisation.
+ Method to release state variables fixed during initialisation.
Keyword Arguments:
flags : dict containing information of which state variables
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/alamo/surrogate_embedding.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/alamo/surrogate_embedding.ipynb
index 9fa9eb01..cc7e8272 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/alamo/surrogate_embedding.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/alamo/surrogate_embedding.ipynb
@@ -34,9 +34,9 @@
"\n",
"## 1. Integration of Surrogate into Custom Property Package\n",
"\n",
- "Here we shall see how to integrate the trained surrogate in the custom property package. One can read more about making a properties package from read the docs. To integrate the surrogate we first define the physical paramter block which will return the properties based on the state variables. State variables would be called from the State Block as Pyomo variables. We will define the surrogate input and output as pyomo variables as well. Once we have defined the variables in the state block then we define our surrogate block.\n",
+ "Here we shall see how to integrate the trained surrogate in the custom property package. One can read more about making a properties package from read the docs. To integrate the surrogate we first define the physical parameter block which will return the properties based on the state variables. State variables would be called from the State Block as Pyomo variables. We will define the surrogate input and output as pyomo variables as well. Once we have defined the variables in the state block then we define our surrogate block.\n",
"\n",
- "*NOTE:* For ease of explaination the property package is written in \".ipynb\" format, ideally it should be in a python script. Each class of this package is separated in different cell for the same reason, in practive all the classes in this notebook should be part of the same python script. This folder includes \"properties.py\" file which is how embedding file should look like. \n",
+ "*NOTE:* For ease of explanation the property package is written in \".ipynb\" format, ideally it should be in a python script. Each class of this package is separated in different cell for the same reason, in practice all the classes in this notebook should be part of the same python script. This folder includes \"properties.py\" file which is how embedding file should look like. \n",
"\n",
"### 1.1 Steps in Creating a Property Package\n",
"Creating a new property package can be broken down into the following steps, which will be demonstrated in the next part of this tutorial.\n",
@@ -107,7 +107,7 @@
"source": [
"# 3 Defining Classes\n",
"\n",
- "We shall be going through each class of the property package in detail. Since there are not reactions occuring in the flowsheet we shall only write the Physical Parameter Block.\n",
+ "We shall be going through each class of the property package in detail. Since there are not reactions occurring in the flowsheet we shall only write the Physical Parameter Block.\n",
"\n",
"## 3.1 Physical Parameter Block\n",
"\n",
@@ -190,7 +190,7 @@
"\n",
"1. Define the input and output variables to the trained surrogate\n",
"2. Load the surrogate from the folder it is saved in, here it is saved in the folder called alamo_surrogate (look at the alamo_training.ipynb file) using the Alamopy Surrogate API of IDAES package\n",
- "3. Define a `SurrogateBlock` and call the build_model method on the block with the input variables, output variables, model formulation and the loaded surrogate as the arguements. \n",
+ "3. Define a `SurrogateBlock` and call the build_model method on the block with the input variables, output variables, model formulation and the loaded surrogate as the arguments. \n",
"4. Define the constraints necessary for ensuring physical feasibility of the system like the mass balance and energy balance. Check for the state variables to be within the bounds. \n"
]
},
@@ -306,7 +306,7 @@
"3. `Return the state of the model` to where it originally started (with the exception of variable values). Any variable that was fixed or constraint that was deactivated during initialization should be unfixed or reactivated, so that the degrees of freedom are restored to what they were before the initialization began.\n",
"\n",
"\n",
- "Thus, we start with fixing the state variables. Here since enth_mol and entr_mol are a function of pressure and temperature, we do not fix them as fixing pressure and temperature would interm fix them. So, we check if a state variable if fixed or not, if it is fixed then we do not change them, if they are not fixed then we check for an initial guess from the `state_args`, if we get a value then we fix the varible with state_args, else we fix it with the value provided by the user. This should bring the degrees of freedom to 0. Here since we do not have any variable/constrained that we have unfixed/deactivated we can skip step 2 and move to step 3. We unfix the variables that were fixed in step 1 using the `release_state` function. "
+ "Thus, we start with fixing the state variables. Here since enth_mol and entr_mol are a function of pressure and temperature, we do not fix them as fixing pressure and temperature would in turn fix them. So, we check if a state variable if fixed or not, if it is fixed then we do not change them, if they are not fixed then we check for an initial guess from the `state_args`, if we get a value then we fix the variable with state_args, else we fix it with the value provided by the user. This should bring the degrees of freedom to 0. Here since we do not have any variable/constrained that we have unfixed/deactivated we can skip step 2 and move to step 3. We unfix the variables that were fixed in step 1 using the `release_state` function. "
]
},
{
@@ -337,7 +337,7 @@
"\n",
" * 0 = no output (default)\n",
" * 1 = return solver state for each step in routine\n",
- " * 2 = include solver output infomation (tee=True)\n",
+ " * 2 = include solver output information (tee=True)\n",
" state_vars_fixed: Flag to denote if state vars have already been\n",
" fixed.\n",
" - True - states have already been fixed by the\n",
@@ -348,18 +348,18 @@
" - False - states have not been fixed. The state\n",
" block will deal with fixing/unfixing.\n",
" optarg : solver options dictionary object (default=None)\n",
- " solver : str indicating whcih solver to use during\n",
+ " solver : str indicating which solver to use during\n",
" initialization (default = 'ipopt')\n",
" hold_state : flag indicating whether the initialization routine\n",
" should unfix any state variables fixed during\n",
" initialization (default=False).\n",
- " - True - states varaibles are not unfixed, and\n",
+ " - True - states variables are not unfixed, and\n",
" a dict of returned containing flags for\n",
" which states were fixed during\n",
" initialization.\n",
" - False - state variables are unfixed after\n",
" initialization by calling the\n",
- " relase_state method\n",
+ " release_state method\n",
"\n",
" Returns:\n",
" If hold_states is True, returns a dict containing flags for\n",
@@ -419,7 +419,7 @@
"\n",
" def release_state(blk, flags, outlvl=0):\n",
" '''\n",
- " Method to relase state variables fixed during initialisation.\n",
+ " Method to release state variables fixed during initialisation.\n",
"\n",
" Keyword Arguments:\n",
" flags : dict containing information of which state variables\n",
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/alamo/surrogate_embedding_doc.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/alamo/surrogate_embedding_doc.ipynb
index 73bf7797..340a1de4 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/alamo/surrogate_embedding_doc.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/alamo/surrogate_embedding_doc.ipynb
@@ -34,9 +34,9 @@
"\n",
"## 1. Integration of Surrogate into Custom Property Package\n",
"\n",
- "Here we shall see how to integrate the trained surrogate in the custom property package. One can read more about making a properties package from read the docs. To integrate the surrogate we first define the physical paramter block which will return the properties based on the state variables. State variables would be called from the State Block as Pyomo variables. We will define the surrogate input and output as pyomo variables as well. Once we have defined the variables in the state block then we define our surrogate block.\n",
+ "Here we shall see how to integrate the trained surrogate in the custom property package. One can read more about making a properties package from read the docs. To integrate the surrogate we first define the physical parameter block which will return the properties based on the state variables. State variables would be called from the State Block as Pyomo variables. We will define the surrogate input and output as pyomo variables as well. Once we have defined the variables in the state block then we define our surrogate block.\n",
"\n",
- "*NOTE:* For ease of explaination the property package is written in \".ipynb\" format, ideally it should be in a python script. Each class of this package is separated in different cell for the same reason, in practive all the classes in this notebook should be part of the same python script. This folder includes \"properties.py\" file which is how embedding file should look like. \n",
+ "*NOTE:* For ease of explanation the property package is written in \".ipynb\" format, ideally it should be in a python script. Each class of this package is separated in different cell for the same reason, in practice all the classes in this notebook should be part of the same python script. This folder includes \"properties.py\" file which is how embedding file should look like. \n",
"\n",
"### 1.1 Steps in Creating a Property Package\n",
"Creating a new property package can be broken down into the following steps, which will be demonstrated in the next part of this tutorial.\n",
@@ -107,7 +107,7 @@
"source": [
"# 3 Defining Classes\n",
"\n",
- "We shall be going through each class of the property package in detail. Since there are not reactions occuring in the flowsheet we shall only write the Physical Parameter Block.\n",
+ "We shall be going through each class of the property package in detail. Since there are not reactions occurring in the flowsheet we shall only write the Physical Parameter Block.\n",
"\n",
"## 3.1 Physical Parameter Block\n",
"\n",
@@ -190,7 +190,7 @@
"\n",
"1. Define the input and output variables to the trained surrogate\n",
"2. Load the surrogate from the folder it is saved in, here it is saved in the folder called alamo_surrogate (look at the alamo_training_doc.md file) using the Alamopy Surrogate API of IDAES package\n",
- "3. Define a `SurrogateBlock` and call the build_model method on the block with the input variables, output variables, model formulation and the loaded surrogate as the arguements. \n",
+ "3. Define a `SurrogateBlock` and call the build_model method on the block with the input variables, output variables, model formulation and the loaded surrogate as the arguments. \n",
"4. Define the constraints necessary for ensuring physical feasibility of the system like the mass balance and energy balance. Check for the state variables to be within the bounds. \n"
]
},
@@ -306,7 +306,7 @@
"3. `Return the state of the model` to where it originally started (with the exception of variable values). Any variable that was fixed or constraint that was deactivated during initialization should be unfixed or reactivated, so that the degrees of freedom are restored to what they were before the initialization began.\n",
"\n",
"\n",
- "Thus, we start with fixing the state variables. Here since enth_mol and entr_mol are a function of pressure and temperature, we do not fix them as fixing pressure and temperature would interm fix them. So, we check if a state variable if fixed or not, if it is fixed then we do not change them, if they are not fixed then we check for an initial guess from the `state_args`, if we get a value then we fix the varible with state_args, else we fix it with the value provided by the user. This should bring the degrees of freedom to 0. Here since we do not have any variable/constrained that we have unfixed/deactivated we can skip step 2 and move to step 3. We unfix the variables that were fixed in step 1 using the `release_state` function. "
+ "Thus, we start with fixing the state variables. Here since enth_mol and entr_mol are a function of pressure and temperature, we do not fix them as fixing pressure and temperature would in turn fix them. So, we check if a state variable if fixed or not, if it is fixed then we do not change them, if they are not fixed then we check for an initial guess from the `state_args`, if we get a value then we fix the variable with state_args, else we fix it with the value provided by the user. This should bring the degrees of freedom to 0. Here since we do not have any variable/constrained that we have unfixed/deactivated we can skip step 2 and move to step 3. We unfix the variables that were fixed in step 1 using the `release_state` function. "
]
},
{
@@ -337,7 +337,7 @@
"\n",
" * 0 = no output (default)\n",
" * 1 = return solver state for each step in routine\n",
- " * 2 = include solver output infomation (tee=True)\n",
+ " * 2 = include solver output information (tee=True)\n",
" state_vars_fixed: Flag to denote if state vars have already been\n",
" fixed.\n",
" - True - states have already been fixed by the\n",
@@ -348,18 +348,18 @@
" - False - states have not been fixed. The state\n",
" block will deal with fixing/unfixing.\n",
" optarg : solver options dictionary object (default=None)\n",
- " solver : str indicating whcih solver to use during\n",
+ " solver : str indicating which solver to use during\n",
" initialization (default = 'ipopt')\n",
" hold_state : flag indicating whether the initialization routine\n",
" should unfix any state variables fixed during\n",
" initialization (default=False).\n",
- " - True - states varaibles are not unfixed, and\n",
+ " - True - states variables are not unfixed, and\n",
" a dict of returned containing flags for\n",
" which states were fixed during\n",
" initialization.\n",
" - False - state variables are unfixed after\n",
" initialization by calling the\n",
- " relase_state method\n",
+ " release_state method\n",
"\n",
" Returns:\n",
" If hold_states is True, returns a dict containing flags for\n",
@@ -419,7 +419,7 @@
"\n",
" def release_state(blk, flags, outlvl=0):\n",
" '''\n",
- " Method to relase state variables fixed during initialisation.\n",
+ " Method to release state variables fixed during initialisation.\n",
"\n",
" Keyword Arguments:\n",
" flags : dict containing information of which state variables\n",
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/alamo/surrogate_embedding_test.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/alamo/surrogate_embedding_test.ipynb
index bf32b875..da1eeb2f 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/alamo/surrogate_embedding_test.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/alamo/surrogate_embedding_test.ipynb
@@ -34,9 +34,9 @@
"\n",
"## 1. Integration of Surrogate into Custom Property Package\n",
"\n",
- "Here we shall see how to integrate the trained surrogate in the custom property package. One can read more about making a properties package from read the docs. To integrate the surrogate we first define the physical paramter block which will return the properties based on the state variables. State variables would be called from the State Block as Pyomo variables. We will define the surrogate input and output as pyomo variables as well. Once we have defined the variables in the state block then we define our surrogate block.\n",
+ "Here we shall see how to integrate the trained surrogate in the custom property package. One can read more about making a properties package from read the docs. To integrate the surrogate we first define the physical parameter block which will return the properties based on the state variables. State variables would be called from the State Block as Pyomo variables. We will define the surrogate input and output as pyomo variables as well. Once we have defined the variables in the state block then we define our surrogate block.\n",
"\n",
- "*NOTE:* For ease of explaination the property package is written in \".ipynb\" format, ideally it should be in a python script. Each class of this package is separated in different cell for the same reason, in practive all the classes in this notebook should be part of the same python script. This folder includes \"properties.py\" file which is how embedding file should look like. \n",
+ "*NOTE:* For ease of explanation the property package is written in \".ipynb\" format, ideally it should be in a python script. Each class of this package is separated in different cell for the same reason, in practice all the classes in this notebook should be part of the same python script. This folder includes \"properties.py\" file which is how embedding file should look like. \n",
"\n",
"### 1.1 Steps in Creating a Property Package\n",
"Creating a new property package can be broken down into the following steps, which will be demonstrated in the next part of this tutorial.\n",
@@ -107,7 +107,7 @@
"source": [
"# 3 Defining Classes\n",
"\n",
- "We shall be going through each class of the property package in detail. Since there are not reactions occuring in the flowsheet we shall only write the Physical Parameter Block.\n",
+ "We shall be going through each class of the property package in detail. Since there are not reactions occurring in the flowsheet we shall only write the Physical Parameter Block.\n",
"\n",
"## 3.1 Physical Parameter Block\n",
"\n",
@@ -190,7 +190,7 @@
"\n",
"1. Define the input and output variables to the trained surrogate\n",
"2. Load the surrogate from the folder it is saved in, here it is saved in the folder called alamo_surrogate (look at the alamo_training_test.ipynb file) using the Alamopy Surrogate API of IDAES package\n",
- "3. Define a `SurrogateBlock` and call the build_model method on the block with the input variables, output variables, model formulation and the loaded surrogate as the arguements. \n",
+ "3. Define a `SurrogateBlock` and call the build_model method on the block with the input variables, output variables, model formulation and the loaded surrogate as the arguments. \n",
"4. Define the constraints necessary for ensuring physical feasibility of the system like the mass balance and energy balance. Check for the state variables to be within the bounds. \n"
]
},
@@ -306,7 +306,7 @@
"3. `Return the state of the model` to where it originally started (with the exception of variable values). Any variable that was fixed or constraint that was deactivated during initialization should be unfixed or reactivated, so that the degrees of freedom are restored to what they were before the initialization began.\n",
"\n",
"\n",
- "Thus, we start with fixing the state variables. Here since enth_mol and entr_mol are a function of pressure and temperature, we do not fix them as fixing pressure and temperature would interm fix them. So, we check if a state variable if fixed or not, if it is fixed then we do not change them, if they are not fixed then we check for an initial guess from the `state_args`, if we get a value then we fix the varible with state_args, else we fix it with the value provided by the user. This should bring the degrees of freedom to 0. Here since we do not have any variable/constrained that we have unfixed/deactivated we can skip step 2 and move to step 3. We unfix the variables that were fixed in step 1 using the `release_state` function. "
+ "Thus, we start with fixing the state variables. Here since enth_mol and entr_mol are a function of pressure and temperature, we do not fix them as fixing pressure and temperature would in turn fix them. So, we check if a state variable if fixed or not, if it is fixed then we do not change them, if they are not fixed then we check for an initial guess from the `state_args`, if we get a value then we fix the variable with state_args, else we fix it with the value provided by the user. This should bring the degrees of freedom to 0. Here since we do not have any variable/constrained that we have unfixed/deactivated we can skip step 2 and move to step 3. We unfix the variables that were fixed in step 1 using the `release_state` function. "
]
},
{
@@ -337,7 +337,7 @@
"\n",
" * 0 = no output (default)\n",
" * 1 = return solver state for each step in routine\n",
- " * 2 = include solver output infomation (tee=True)\n",
+ " * 2 = include solver output information (tee=True)\n",
" state_vars_fixed: Flag to denote if state vars have already been\n",
" fixed.\n",
" - True - states have already been fixed by the\n",
@@ -348,18 +348,18 @@
" - False - states have not been fixed. The state\n",
" block will deal with fixing/unfixing.\n",
" optarg : solver options dictionary object (default=None)\n",
- " solver : str indicating whcih solver to use during\n",
+ " solver : str indicating which solver to use during\n",
" initialization (default = 'ipopt')\n",
" hold_state : flag indicating whether the initialization routine\n",
" should unfix any state variables fixed during\n",
" initialization (default=False).\n",
- " - True - states varaibles are not unfixed, and\n",
+ " - True - states variables are not unfixed, and\n",
" a dict of returned containing flags for\n",
" which states were fixed during\n",
" initialization.\n",
" - False - state variables are unfixed after\n",
" initialization by calling the\n",
- " relase_state method\n",
+ " release_state method\n",
"\n",
" Returns:\n",
" If hold_states is True, returns a dict containing flags for\n",
@@ -419,7 +419,7 @@
"\n",
" def release_state(blk, flags, outlvl=0):\n",
" '''\n",
- " Method to relase state variables fixed during initialisation.\n",
+ " Method to release state variables fixed during initialisation.\n",
"\n",
" Keyword Arguments:\n",
" flags : dict containing information of which state variables\n",
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/alamo/surrogate_embedding_usr.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/alamo/surrogate_embedding_usr.ipynb
index 184fc468..61223b2b 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/alamo/surrogate_embedding_usr.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/alamo/surrogate_embedding_usr.ipynb
@@ -34,9 +34,9 @@
"\n",
"## 1. Integration of Surrogate into Custom Property Package\n",
"\n",
- "Here we shall see how to integrate the trained surrogate in the custom property package. One can read more about making a properties package from read the docs. To integrate the surrogate we first define the physical paramter block which will return the properties based on the state variables. State variables would be called from the State Block as Pyomo variables. We will define the surrogate input and output as pyomo variables as well. Once we have defined the variables in the state block then we define our surrogate block.\n",
+ "Here we shall see how to integrate the trained surrogate in the custom property package. One can read more about making a properties package from read the docs. To integrate the surrogate we first define the physical parameter block which will return the properties based on the state variables. State variables would be called from the State Block as Pyomo variables. We will define the surrogate input and output as pyomo variables as well. Once we have defined the variables in the state block then we define our surrogate block.\n",
"\n",
- "*NOTE:* For ease of explaination the property package is written in \".ipynb\" format, ideally it should be in a python script. Each class of this package is separated in different cell for the same reason, in practive all the classes in this notebook should be part of the same python script. This folder includes \"properties.py\" file which is how embedding file should look like. \n",
+ "*NOTE:* For ease of explanation the property package is written in \".ipynb\" format, ideally it should be in a python script. Each class of this package is separated in different cell for the same reason, in practice all the classes in this notebook should be part of the same python script. This folder includes \"properties.py\" file which is how embedding file should look like. \n",
"\n",
"### 1.1 Steps in Creating a Property Package\n",
"Creating a new property package can be broken down into the following steps, which will be demonstrated in the next part of this tutorial.\n",
@@ -110,7 +110,7 @@
"source": [
"# 3 Defining Classes\n",
"\n",
- "We shall be going through each class of the property package in detail. Since there are not reactions occuring in the flowsheet we shall only write the Physical Parameter Block.\n",
+ "We shall be going through each class of the property package in detail. Since there are not reactions occurring in the flowsheet we shall only write the Physical Parameter Block.\n",
"\n",
"## 3.1 Physical Parameter Block\n",
"\n",
@@ -193,7 +193,7 @@
"\n",
"1. Define the input and output variables to the trained surrogate\n",
"2. Load the surrogate from the folder it is saved in, here it is saved in the folder called alamo_surrogate (look at the alamo_training_usr.ipynb file) using the Alamopy Surrogate API of IDAES package\n",
- "3. Define a `SurrogateBlock` and call the build_model method on the block with the input variables, output variables, model formulation and the loaded surrogate as the arguements. \n",
+ "3. Define a `SurrogateBlock` and call the build_model method on the block with the input variables, output variables, model formulation and the loaded surrogate as the arguments. \n",
"4. Define the constraints necessary for ensuring physical feasibility of the system like the mass balance and energy balance. Check for the state variables to be within the bounds. \n"
]
},
@@ -309,7 +309,7 @@
"3. `Return the state of the model` to where it originally started (with the exception of variable values). Any variable that was fixed or constraint that was deactivated during initialization should be unfixed or reactivated, so that the degrees of freedom are restored to what they were before the initialization began.\n",
"\n",
"\n",
- "Thus, we start with fixing the state variables. Here since enth_mol and entr_mol are a function of pressure and temperature, we do not fix them as fixing pressure and temperature would interm fix them. So, we check if a state variable if fixed or not, if it is fixed then we do not change them, if they are not fixed then we check for an initial guess from the `state_args`, if we get a value then we fix the varible with state_args, else we fix it with the value provided by the user. This should bring the degrees of freedom to 0. Here since we do not have any variable/constrained that we have unfixed/deactivated we can skip step 2 and move to step 3. We unfix the variables that were fixed in step 1 using the `release_state` function. "
+ "Thus, we start with fixing the state variables. Here since enth_mol and entr_mol are a function of pressure and temperature, we do not fix them as fixing pressure and temperature would in turn fix them. So, we check if a state variable if fixed or not, if it is fixed then we do not change them, if they are not fixed then we check for an initial guess from the `state_args`, if we get a value then we fix the variable with state_args, else we fix it with the value provided by the user. This should bring the degrees of freedom to 0. Here since we do not have any variable/constrained that we have unfixed/deactivated we can skip step 2 and move to step 3. We unfix the variables that were fixed in step 1 using the `release_state` function. "
]
},
{
@@ -340,7 +340,7 @@
"\n",
" * 0 = no output (default)\n",
" * 1 = return solver state for each step in routine\n",
- " * 2 = include solver output infomation (tee=True)\n",
+ " * 2 = include solver output information (tee=True)\n",
" state_vars_fixed: Flag to denote if state vars have already been\n",
" fixed.\n",
" - True - states have already been fixed by the\n",
@@ -351,18 +351,18 @@
" - False - states have not been fixed. The state\n",
" block will deal with fixing/unfixing.\n",
" optarg : solver options dictionary object (default=None)\n",
- " solver : str indicating whcih solver to use during\n",
+ " solver : str indicating which solver to use during\n",
" initialization (default = 'ipopt')\n",
" hold_state : flag indicating whether the initialization routine\n",
" should unfix any state variables fixed during\n",
" initialization (default=False).\n",
- " - True - states varaibles are not unfixed, and\n",
+ " - True - states variables are not unfixed, and\n",
" a dict of returned containing flags for\n",
" which states were fixed during\n",
" initialization.\n",
" - False - state variables are unfixed after\n",
" initialization by calling the\n",
- " relase_state method\n",
+ " release_state method\n",
"\n",
" Returns:\n",
" If hold_states is True, returns a dict containing flags for\n",
@@ -422,7 +422,7 @@
"\n",
" def release_state(blk, flags, outlvl=0):\n",
" '''\n",
- " Method to relase state variables fixed during initialisation.\n",
+ " Method to release state variables fixed during initialisation.\n",
"\n",
" Keyword Arguments:\n",
" flags : dict containing information of which state variables\n",
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/omlt/flowsheet_optimization.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/omlt/flowsheet_optimization.ipynb
index 2e240888..5a17df37 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/omlt/flowsheet_optimization.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/omlt/flowsheet_optimization.ipynb
@@ -120,7 +120,7 @@
"source": [
"# 2. Constructing the flowsheet\n",
"\n",
- "To construct the flowsheet we need to define a ConcreteModel using pyomo and then add a FlowsheetBlock to the ConcreteModel. Here since we are focusing on the steady state process, we shall have the dynamic flag as False in the FlowsheetBlock. Next, we define the properties in the FlowsheetBlock that we imported from the properties.py file. Then start adding the unit models to the FlowsheetBlock with the suitable arguements, after which we connect them using Arcs as in the flowsheet above. \n",
+ "To construct the flowsheet we need to define a ConcreteModel using pyomo and then add a FlowsheetBlock to the ConcreteModel. Here since we are focusing on the steady state process, we shall have the dynamic flag as False in the FlowsheetBlock. Next, we define the properties in the FlowsheetBlock that we imported from the properties.py file. Then start adding the unit models to the FlowsheetBlock with the suitable arguments, after which we connect them using Arcs as in the flowsheet above. \n",
"\n",
"Once we have the connected flowsheet, we initialize individual unit models. Before initializing, we fix desired variables for the desired behavior of the unit model and then use `propagate_state` to pass on the state variables to next unit model in the flowsheet. After completely initializing the flowsheet, we convert the network to a mathematical form by using `network.expand_arcs` from the TransformationFactory and apply it on the flowsheet block. Then we call the solver and solve the flowsheet to calculate the total work in the process. "
]
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/omlt/flowsheet_optimization_doc.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/omlt/flowsheet_optimization_doc.ipynb
index 44f8241f..921a163b 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/omlt/flowsheet_optimization_doc.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/omlt/flowsheet_optimization_doc.ipynb
@@ -110,7 +110,7 @@
"source": [
"# 2. Constructing the flowsheet\n",
"\n",
- "To construct the flowsheet we need to define a ConcreteModel using pyomo and then add a FlowsheetBlock to the ConcreteModel. Here since we are focusing on the steady state process, we shall have the dynamic flag as False in the FlowsheetBlock. Next, we define the properties in the FlowsheetBlock that we imported from the properties.py file. Then start adding the unit models to the FlowsheetBlock with the suitable arguements, after which we connect them using Arcs as in the flowsheet above. \n",
+ "To construct the flowsheet we need to define a ConcreteModel using pyomo and then add a FlowsheetBlock to the ConcreteModel. Here since we are focusing on the steady state process, we shall have the dynamic flag as False in the FlowsheetBlock. Next, we define the properties in the FlowsheetBlock that we imported from the properties.py file. Then start adding the unit models to the FlowsheetBlock with the suitable arguments, after which we connect them using Arcs as in the flowsheet above. \n",
"\n",
"Once we have the connected flowsheet, we initialize individual unit models. Before initializing, we fix desired variables for the desired behavior of the unit model and then use `propagate_state` to pass on the state variables to next unit model in the flowsheet. After completely initializing the flowsheet, we convert the network to a mathematical form by using `network.expand_arcs` from the TransformationFactory and apply it on the flowsheet block. Then we call the solver and solve the flowsheet to calculate the total work in the process. "
]
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/omlt/flowsheet_optimization_test.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/omlt/flowsheet_optimization_test.ipynb
index b8ed26f3..45b7dd73 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/omlt/flowsheet_optimization_test.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/omlt/flowsheet_optimization_test.ipynb
@@ -110,7 +110,7 @@
"source": [
"# 2. Constructing the flowsheet\n",
"\n",
- "To construct the flowsheet we need to define a ConcreteModel using pyomo and then add a FlowsheetBlock to the ConcreteModel. Here since we are focusing on the steady state process, we shall have the dynamic flag as False in the FlowsheetBlock. Next, we define the properties in the FlowsheetBlock that we imported from the properties.py file. Then start adding the unit models to the FlowsheetBlock with the suitable arguements, after which we connect them using Arcs as in the flowsheet above. \n",
+ "To construct the flowsheet we need to define a ConcreteModel using pyomo and then add a FlowsheetBlock to the ConcreteModel. Here since we are focusing on the steady state process, we shall have the dynamic flag as False in the FlowsheetBlock. Next, we define the properties in the FlowsheetBlock that we imported from the properties.py file. Then start adding the unit models to the FlowsheetBlock with the suitable arguments, after which we connect them using Arcs as in the flowsheet above. \n",
"\n",
"Once we have the connected flowsheet, we initialize individual unit models. Before initializing, we fix desired variables for the desired behavior of the unit model and then use `propagate_state` to pass on the state variables to next unit model in the flowsheet. After completely initializing the flowsheet, we convert the network to a mathematical form by using `network.expand_arcs` from the TransformationFactory and apply it on the flowsheet block. Then we call the solver and solve the flowsheet to calculate the total work in the process. "
]
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/omlt/flowsheet_optimization_usr.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/omlt/flowsheet_optimization_usr.ipynb
index b8ed26f3..45b7dd73 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/omlt/flowsheet_optimization_usr.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/omlt/flowsheet_optimization_usr.ipynb
@@ -110,7 +110,7 @@
"source": [
"# 2. Constructing the flowsheet\n",
"\n",
- "To construct the flowsheet we need to define a ConcreteModel using pyomo and then add a FlowsheetBlock to the ConcreteModel. Here since we are focusing on the steady state process, we shall have the dynamic flag as False in the FlowsheetBlock. Next, we define the properties in the FlowsheetBlock that we imported from the properties.py file. Then start adding the unit models to the FlowsheetBlock with the suitable arguements, after which we connect them using Arcs as in the flowsheet above. \n",
+ "To construct the flowsheet we need to define a ConcreteModel using pyomo and then add a FlowsheetBlock to the ConcreteModel. Here since we are focusing on the steady state process, we shall have the dynamic flag as False in the FlowsheetBlock. Next, we define the properties in the FlowsheetBlock that we imported from the properties.py file. Then start adding the unit models to the FlowsheetBlock with the suitable arguments, after which we connect them using Arcs as in the flowsheet above. \n",
"\n",
"Once we have the connected flowsheet, we initialize individual unit models. Before initializing, we fix desired variables for the desired behavior of the unit model and then use `propagate_state` to pass on the state variables to next unit model in the flowsheet. After completely initializing the flowsheet, we convert the network to a mathematical form by using `network.expand_arcs` from the TransformationFactory and apply it on the flowsheet block. Then we call the solver and solve the flowsheet to calculate the total work in the process. "
]
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/omlt/keras_training.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/omlt/keras_training.ipynb
index 9acc449d..32827f85 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/omlt/keras_training.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/omlt/keras_training.ipynb
@@ -42,7 +42,7 @@
"### 1.1 Need for ML Surrogates\n",
"\n",
"The properties predicted by the surrogate are enthalpy and entropy of the S-CO2 based on the \n",
- "pressure and temperature of the system. The analytical equation of getting the enthalpy and entropy from pressure and temperature are in the differential form and would make the problem a DAE system. To counter this problem and keep the problem algebric, we will use the ML surrogates and relate enthalpy and entropy with the pressure and temperature as an algebric equation.\n",
+ "pressure and temperature of the system. The analytical equation of getting the enthalpy and entropy from pressure and temperature are in the differential form and would make the problem a DAE system. To counter this problem and keep the problem algebraic, we will use the ML surrogates and relate enthalpy and entropy with the pressure and temperature as an algebraic equation.\n",
"\n",
"### 1.2 Supercritical CO2 cycle process\n",
"\n",
@@ -139,7 +139,7 @@
"\n",
"In this section, we read the dataset from the CSV file located in this directory. 500 data points were simulated for S-CO2 physical properties using REFPROP package. This example is trained on the entire dataset because neural network can overfit on smaller dataset. The data is separated using an 80/20 split into training and validation data using the IDAES split_training_validation() method.\n",
"\n",
- "We rename the column headers because they contained \".\", which may cause errors while reading the column names in subsquent code, thus as a good practice we change them to the variable names to be used in the property package. Further, the input variables are **pressure**, **temperature** , while the output variables are **enth_mol**, **entr_mol**, hence we create two new dataframes for the input and output variables. "
+ "We rename the column headers because they contained \".\", which may cause errors while reading the column names in subsequent code, thus as a good practice we change them to the variable names to be used in the property package. Further, the input variables are **pressure**, **temperature** , while the output variables are **enth_mol**, **entr_mol**, hence we create two new dataframes for the input and output variables. "
]
},
{
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/omlt/keras_training_doc.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/omlt/keras_training_doc.ipynb
index 4b4d5aab..79bbaf1d 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/omlt/keras_training_doc.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/omlt/keras_training_doc.ipynb
@@ -42,7 +42,7 @@
"### 1.1 Need for ML Surrogates\n",
"\n",
"The properties predicted by the surrogate are enthalpy and entropy of the S-CO2 based on the \n",
- "pressure and temperature of the system. The analytical equation of getting the enthalpy and entropy from pressure and temperature are in the differential form and would make the problem a DAE system. To counter this problem and keep the problem algebric, we will use the ML surrogates and relate enthalpy and entropy with the pressure and temperature as an algebric equation.\n",
+ "pressure and temperature of the system. The analytical equation of getting the enthalpy and entropy from pressure and temperature are in the differential form and would make the problem a DAE system. To counter this problem and keep the problem algebraic, we will use the ML surrogates and relate enthalpy and entropy with the pressure and temperature as an algebraic equation.\n",
"\n",
"### 1.2 Supercritical CO2 cycle process\n",
"\n",
@@ -129,7 +129,7 @@
"\n",
"In this section, we read the dataset from the CSV file located in this directory. 500 data points were simulated for S-CO2 physical properties using REFPROP package. This example is trained on the entire dataset because neural network can overfit on smaller dataset. The data is separated using an 80/20 split into training and validation data using the IDAES split_training_validation() method.\n",
"\n",
- "We rename the column headers because they contained \".\", which may cause errors while reading the column names in subsquent code, thus as a good practice we change them to the variable names to be used in the property package. Further, the input variables are **pressure**, **temperature** , while the output variables are **enth_mol**, **entr_mol**, hence we create two new dataframes for the input and output variables. "
+ "We rename the column headers because they contained \".\", which may cause errors while reading the column names in subsequent code, thus as a good practice we change them to the variable names to be used in the property package. Further, the input variables are **pressure**, **temperature** , while the output variables are **enth_mol**, **entr_mol**, hence we create two new dataframes for the input and output variables. "
]
},
{
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/omlt/keras_training_test.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/omlt/keras_training_test.ipynb
index cacf5254..a4c68e87 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/omlt/keras_training_test.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/omlt/keras_training_test.ipynb
@@ -42,7 +42,7 @@
"### 1.1 Need for ML Surrogates\n",
"\n",
"The properties predicted by the surrogate are enthalpy and entropy of the S-CO2 based on the \n",
- "pressure and temperature of the system. The analytical equation of getting the enthalpy and entropy from pressure and temperature are in the differential form and would make the problem a DAE system. To counter this problem and keep the problem algebric, we will use the ML surrogates and relate enthalpy and entropy with the pressure and temperature as an algebric equation.\n",
+ "pressure and temperature of the system. The analytical equation of getting the enthalpy and entropy from pressure and temperature are in the differential form and would make the problem a DAE system. To counter this problem and keep the problem algebraic, we will use the ML surrogates and relate enthalpy and entropy with the pressure and temperature as an algebraic equation.\n",
"\n",
"### 1.2 Supercritical CO2 cycle process\n",
"\n",
@@ -129,7 +129,7 @@
"\n",
"In this section, we read the dataset from the CSV file located in this directory. 500 data points were simulated for S-CO2 physical properties using REFPROP package. This example is trained on the entire dataset because neural network can overfit on smaller dataset. The data is separated using an 80/20 split into training and validation data using the IDAES split_training_validation() method.\n",
"\n",
- "We rename the column headers because they contained \".\", which may cause errors while reading the column names in subsquent code, thus as a good practice we change them to the variable names to be used in the property package. Further, the input variables are **pressure**, **temperature** , while the output variables are **enth_mol**, **entr_mol**, hence we create two new dataframes for the input and output variables. "
+ "We rename the column headers because they contained \".\", which may cause errors while reading the column names in subsequent code, thus as a good practice we change them to the variable names to be used in the property package. Further, the input variables are **pressure**, **temperature** , while the output variables are **enth_mol**, **entr_mol**, hence we create two new dataframes for the input and output variables. "
]
},
{
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/omlt/keras_training_usr.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/omlt/keras_training_usr.ipynb
index 0b0c7558..f59ea874 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/omlt/keras_training_usr.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/omlt/keras_training_usr.ipynb
@@ -42,7 +42,7 @@
"### 1.1 Need for ML Surrogates\n",
"\n",
"The properties predicted by the surrogate are enthalpy and entropy of the S-CO2 based on the \n",
- "pressure and temperature of the system. The analytical equation of getting the enthalpy and entropy from pressure and temperature are in the differential form and would make the problem a DAE system. To counter this problem and keep the problem algebric, we will use the ML surrogates and relate enthalpy and entropy with the pressure and temperature as an algebric equation.\n",
+ "pressure and temperature of the system. The analytical equation of getting the enthalpy and entropy from pressure and temperature are in the differential form and would make the problem a DAE system. To counter this problem and keep the problem algebraic, we will use the ML surrogates and relate enthalpy and entropy with the pressure and temperature as an algebraic equation.\n",
"\n",
"### 1.2 Supercritical CO2 cycle process\n",
"\n",
@@ -129,7 +129,7 @@
"\n",
"In this section, we read the dataset from the CSV file located in this directory. 500 data points were simulated for S-CO2 physical properties using REFPROP package. This example is trained on the entire dataset because neural network can overfit on smaller dataset. The data is separated using an 80/20 split into training and validation data using the IDAES split_training_validation() method.\n",
"\n",
- "We rename the column headers because they contained \".\", which may cause errors while reading the column names in subsquent code, thus as a good practice we change them to the variable names to be used in the property package. Further, the input variables are **pressure**, **temperature** , while the output variables are **enth_mol**, **entr_mol**, hence we create two new dataframes for the input and output variables. "
+ "We rename the column headers because they contained \".\", which may cause errors while reading the column names in subsequent code, thus as a good practice we change them to the variable names to be used in the property package. Further, the input variables are **pressure**, **temperature** , while the output variables are **enth_mol**, **entr_mol**, hence we create two new dataframes for the input and output variables. "
]
},
{
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/omlt/properties.py b/idaes_examples/notebooks/docs/surrogates/sco2/omlt/properties.py
index 64101604..bde029c3 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/omlt/properties.py
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/omlt/properties.py
@@ -118,7 +118,7 @@ def initialize(blk, state_args=None, hold_state=False, outlvl=1,
* 0 = no output (default)
* 1 = return solver state for each step in routine
- * 2 = include solver output infomation (tee=True)
+ * 2 = include solver output information (tee=True)
state_vars_fixed: Flag to denote if state vars have already been
fixed.
- True - states have already been fixed by the
@@ -129,18 +129,18 @@ def initialize(blk, state_args=None, hold_state=False, outlvl=1,
- False - states have not been fixed. The state
block will deal with fixing/unfixing.
optarg : solver options dictionary object (default=None)
- solver : str indicating whcih solver to use during
+ solver : str indicating which 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).
- - True - states varaibles are not unfixed, and
+ - 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
- relase_state method
+ release_state method
Returns:
If hold_states is True, returns a dict containing flags for
@@ -200,7 +200,7 @@ def initialize(blk, state_args=None, hold_state=False, outlvl=1,
def release_state(blk, flags, outlvl=0):
'''
- Method to relase state variables fixed during initialisation.
+ Method to release state variables fixed during initialisation.
Keyword Arguments:
flags : dict containing information of which state variables
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/omlt/surrogate_embedding.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/omlt/surrogate_embedding.ipynb
index 3af20892..a83738c4 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/omlt/surrogate_embedding.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/omlt/surrogate_embedding.ipynb
@@ -34,9 +34,9 @@
"\n",
"## 1. Integration of Surrogate into Custom Property Package\n",
"\n",
- "Here we shall see how to integrate the trained surrogate in the custom property package. One can read more about making a properties package from read the docs. To integrate the surrogate we first define the physical paramter block which will return the properties based on the state variables. State variables would be called from the State Block as Pyomo variables. We will define the surrogate input and output as pyomo variables as well. Once we have defined the variables in the state block then we define our surrogate block.\n",
+ "Here we shall see how to integrate the trained surrogate in the custom property package. One can read more about making a properties package from read the docs. To integrate the surrogate we first define the physical parameter block which will return the properties based on the state variables. State variables would be called from the State Block as Pyomo variables. We will define the surrogate input and output as pyomo variables as well. Once we have defined the variables in the state block then we define our surrogate block.\n",
"\n",
- "*NOTE:* For ease of explaination the property package is written in \".ipynb\" format, ideally it should be in a python script. Each class of this package is separated in different cell for the same reason, in practive all the classes in this notebook should be part of the same python script. This folder includes \"properties.py\" file which is how embedding file should look like. \n",
+ "*NOTE:* For ease of explanation the property package is written in \".ipynb\" format, ideally it should be in a python script. Each class of this package is separated in different cell for the same reason, in practice all the classes in this notebook should be part of the same python script. This folder includes \"properties.py\" file which is how embedding file should look like. \n",
"\n",
"### 1.1 Steps in Creating a Property Package\n",
"Creating a new property package can be broken down into the following steps, which will be demonstrated in the next part of this tutorial.\n",
@@ -107,7 +107,7 @@
"source": [
"# 3 Defining Classes\n",
"\n",
- "We shall be going through each class of the property package in detail. Since there are not reactions occuring in the flowsheet we shall only write the Physical Parameter Block.\n",
+ "We shall be going through each class of the property package in detail. Since there are not reactions occurring in the flowsheet we shall only write the Physical Parameter Block.\n",
"\n",
"## 3.1 Physical Parameter Block\n",
"\n",
@@ -190,7 +190,7 @@
"\n",
"1. Define the input and output variables to the trained surrogate\n",
"2. Load the surrogate from the folder it is saved in, here it is saved in the folder called keras_surrogate (look at the keras_training.ipynb file) using the keras Surrogate API of IDAES package\n",
- "3. Define a `SurrogateBlock` and call the build_model method on the block with the input variables, output variables, model formulation and the loaded surrogate as the arguements. \n",
+ "3. Define a `SurrogateBlock` and call the build_model method on the block with the input variables, output variables, model formulation and the loaded surrogate as the arguments. \n",
"4. Define the constraints necessary for ensuring physical feasibility of the system like the mass balance and energy balance. Check for the state variables to be within the bounds. \n"
]
},
@@ -301,7 +301,7 @@
"3. `Return the state of the model` to where it originally started (with the exception of variable values). Any variable that was fixed or constraint that was deactivated during initialization should be unfixed or reactivated, so that the degrees of freedom are restored to what they were before the initialization began.\n",
"\n",
"\n",
- "Thus, we start with fixing the state variables. Here since enth_mol and entr_mol are a function of pressure and temperature, we do not fix them as fixing pressure and temperature would interm fix them. So, we check if a state variable if fixed or not, if it is fixed then we do not change them, if they are not fixed then we check for an initial guess from the `state_args`, if we get a value then we fix the varible with state_args, else we fix it with the value provided by the user. This should bring the degrees of freedom to 0. Here since we do not have any variable/constrained that we have unfixed/deactivated we can skip step 2 and move to step 3. We unfix the variables that were fixed in step 1 using the `release_state` function. "
+ "Thus, we start with fixing the state variables. Here since enth_mol and entr_mol are a function of pressure and temperature, we do not fix them as fixing pressure and temperature would inturn fix them. So, we check if a state variable if fixed or not, if it is fixed then we do not change them, if they are not fixed then we check for an initial guess from the `state_args`, if we get a value then we fix the variable with state_args, else we fix it with the value provided by the user. This should bring the degrees of freedom to 0. Here since we do not have any variable/constrained that we have unfixed/deactivated we can skip step 2 and move to step 3. We unfix the variables that were fixed in step 1 using the `release_state` function. "
]
},
{
@@ -332,7 +332,7 @@
"\n",
" * 0 = no output (default)\n",
" * 1 = return solver state for each step in routine\n",
- " * 2 = include solver output infomation (tee=True)\n",
+ " * 2 = include solver output information (tee=True)\n",
" state_vars_fixed: Flag to denote if state vars have already been\n",
" fixed.\n",
" - True - states have already been fixed by the\n",
@@ -343,18 +343,18 @@
" - False - states have not been fixed. The state\n",
" block will deal with fixing/unfixing.\n",
" optarg : solver options dictionary object (default=None)\n",
- " solver : str indicating whcih solver to use during\n",
+ " solver : str indicating which solver to use during\n",
" initialization (default = 'ipopt')\n",
" hold_state : flag indicating whether the initialization routine\n",
" should unfix any state variables fixed during\n",
" initialization (default=False).\n",
- " - True - states varaibles are not unfixed, and\n",
+ " - True - states variables are not unfixed, and\n",
" a dict of returned containing flags for\n",
" which states were fixed during\n",
" initialization.\n",
" - False - state variables are unfixed after\n",
" initialization by calling the\n",
- " relase_state method\n",
+ " release_state method\n",
"\n",
" Returns:\n",
" If hold_states is True, returns a dict containing flags for\n",
@@ -414,7 +414,7 @@
"\n",
" def release_state(blk, flags, outlvl=0):\n",
" '''\n",
- " Method to relase state variables fixed during initialisation.\n",
+ " Method to release state variables fixed during initialisation.\n",
"\n",
" Keyword Arguments:\n",
" flags : dict containing information of which state variables\n",
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/omlt/surrogate_embedding_doc.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/omlt/surrogate_embedding_doc.ipynb
index dba5cb3d..d880c31c 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/omlt/surrogate_embedding_doc.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/omlt/surrogate_embedding_doc.ipynb
@@ -33,9 +33,9 @@
"Updated: 2024-01-24\n",
"## 1. Integration of Surrogate into Custom Property Package\n",
"\n",
- "Here we shall see how to integrate the trained surrogate in the custom property package. One can read more about making a properties package from read the docs. To integrate the surrogate we first define the physical paramter block which will return the properties based on the state variables. State variables would be called from the State Block as Pyomo variables. We will define the surrogate input and output as pyomo variables as well. Once we have defined the variables in the state block then we define our surrogate block.\n",
+ "Here we shall see how to integrate the trained surrogate in the custom property package. One can read more about making a properties package from read the docs. To integrate the surrogate we first define the physical parameter block which will return the properties based on the state variables. State variables would be called from the State Block as Pyomo variables. We will define the surrogate input and output as pyomo variables as well. Once we have defined the variables in the state block then we define our surrogate block.\n",
"\n",
- "*NOTE:* For ease of explaination the property package is written in \".ipynb\" format, ideally it should be in a python script. Each class of this package is separated in different cell for the same reason, in practive all the classes in this notebook should be part of the same python script. This folder includes \"properties.py\" file which is how embedding file should look like. \n",
+ "*NOTE:* For ease of explanation the property package is written in \".ipynb\" format, ideally it should be in a python script. Each class of this package is separated in different cell for the same reason, in practice all the classes in this notebook should be part of the same python script. This folder includes \"properties.py\" file which is how embedding file should look like. \n",
"\n",
"### 1.1 Steps in Creating a Property Package\n",
"Creating a new property package can be broken down into the following steps, which will be demonstrated in the next part of this tutorial.\n",
@@ -106,7 +106,7 @@
"source": [
"# 3 Defining Classes\n",
"\n",
- "We shall be going through each class of the property package in detail. Since there are not reactions occuring in the flowsheet we shall only write the Physical Parameter Block.\n",
+ "We shall be going through each class of the property package in detail. Since there are not reactions occurring in the flowsheet we shall only write the Physical Parameter Block.\n",
"\n",
"## 3.1 Physical Parameter Block\n",
"\n",
@@ -189,7 +189,7 @@
"\n",
"1. Define the input and output variables to the trained surrogate\n",
"2. Load the surrogate from the folder it is saved in, here it is saved in the folder called keras_surrogate (look at the keras_training_doc.md file) using the keras Surrogate API of IDAES package\n",
- "3. Define a `SurrogateBlock` and call the build_model method on the block with the input variables, output variables, model formulation and the loaded surrogate as the arguements. \n",
+ "3. Define a `SurrogateBlock` and call the build_model method on the block with the input variables, output variables, model formulation and the loaded surrogate as the arguments. \n",
"4. Define the constraints necessary for ensuring physical feasibility of the system like the mass balance and energy balance. Check for the state variables to be within the bounds. \n"
]
},
@@ -300,7 +300,7 @@
"3. `Return the state of the model` to where it originally started (with the exception of variable values). Any variable that was fixed or constraint that was deactivated during initialization should be unfixed or reactivated, so that the degrees of freedom are restored to what they were before the initialization began.\n",
"\n",
"\n",
- "Thus, we start with fixing the state variables. Here since enth_mol and entr_mol are a function of pressure and temperature, we do not fix them as fixing pressure and temperature would interm fix them. So, we check if a state variable if fixed or not, if it is fixed then we do not change them, if they are not fixed then we check for an initial guess from the `state_args`, if we get a value then we fix the varible with state_args, else we fix it with the value provided by the user. This should bring the degrees of freedom to 0. Here since we do not have any variable/constrained that we have unfixed/deactivated we can skip step 2 and move to step 3. We unfix the variables that were fixed in step 1 using the `release_state` function. "
+ "Thus, we start with fixing the state variables. Here since enth_mol and entr_mol are a function of pressure and temperature, we do not fix them as fixing pressure and temperature would inturn fix them. So, we check if a state variable if fixed or not, if it is fixed then we do not change them, if they are not fixed then we check for an initial guess from the `state_args`, if we get a value then we fix the variable with state_args, else we fix it with the value provided by the user. This should bring the degrees of freedom to 0. Here since we do not have any variable/constrained that we have unfixed/deactivated we can skip step 2 and move to step 3. We unfix the variables that were fixed in step 1 using the `release_state` function. "
]
},
{
@@ -331,7 +331,7 @@
"\n",
" * 0 = no output (default)\n",
" * 1 = return solver state for each step in routine\n",
- " * 2 = include solver output infomation (tee=True)\n",
+ " * 2 = include solver output information (tee=True)\n",
" state_vars_fixed: Flag to denote if state vars have already been\n",
" fixed.\n",
" - True - states have already been fixed by the\n",
@@ -342,18 +342,18 @@
" - False - states have not been fixed. The state\n",
" block will deal with fixing/unfixing.\n",
" optarg : solver options dictionary object (default=None)\n",
- " solver : str indicating whcih solver to use during\n",
+ " solver : str indicating which solver to use during\n",
" initialization (default = 'ipopt')\n",
" hold_state : flag indicating whether the initialization routine\n",
" should unfix any state variables fixed during\n",
" initialization (default=False).\n",
- " - True - states varaibles are not unfixed, and\n",
+ " - True - states variables are not unfixed, and\n",
" a dict of returned containing flags for\n",
" which states were fixed during\n",
" initialization.\n",
" - False - state variables are unfixed after\n",
" initialization by calling the\n",
- " relase_state method\n",
+ " release_state method\n",
"\n",
" Returns:\n",
" If hold_states is True, returns a dict containing flags for\n",
@@ -413,7 +413,7 @@
"\n",
" def release_state(blk, flags, outlvl=0):\n",
" '''\n",
- " Method to relase state variables fixed during initialisation.\n",
+ " Method to release state variables fixed during initialisation.\n",
"\n",
" Keyword Arguments:\n",
" flags : dict containing information of which state variables\n",
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/omlt/surrogate_embedding_test.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/omlt/surrogate_embedding_test.ipynb
index cdd26cd6..d3328bcd 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/omlt/surrogate_embedding_test.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/omlt/surrogate_embedding_test.ipynb
@@ -33,9 +33,9 @@
"Updated: 2024-01-24\n",
"## 1. Integration of Surrogate into Custom Property Package\n",
"\n",
- "Here we shall see how to integrate the trained surrogate in the custom property package. One can read more about making a properties package from read the docs. To integrate the surrogate we first define the physical paramter block which will return the properties based on the state variables. State variables would be called from the State Block as Pyomo variables. We will define the surrogate input and output as pyomo variables as well. Once we have defined the variables in the state block then we define our surrogate block.\n",
+ "Here we shall see how to integrate the trained surrogate in the custom property package. One can read more about making a properties package from read the docs. To integrate the surrogate we first define the physical parameter block which will return the properties based on the state variables. State variables would be called from the State Block as Pyomo variables. We will define the surrogate input and output as pyomo variables as well. Once we have defined the variables in the state block then we define our surrogate block.\n",
"\n",
- "*NOTE:* For ease of explaination the property package is written in \".ipynb\" format, ideally it should be in a python script. Each class of this package is separated in different cell for the same reason, in practive all the classes in this notebook should be part of the same python script. This folder includes \"properties.py\" file which is how embedding file should look like. \n",
+ "*NOTE:* For ease of explanation the property package is written in \".ipynb\" format, ideally it should be in a python script. Each class of this package is separated in different cell for the same reason, in practice all the classes in this notebook should be part of the same python script. This folder includes \"properties.py\" file which is how embedding file should look like. \n",
"\n",
"### 1.1 Steps in Creating a Property Package\n",
"Creating a new property package can be broken down into the following steps, which will be demonstrated in the next part of this tutorial.\n",
@@ -108,7 +108,7 @@
"source": [
"# 3 Defining Classes\n",
"\n",
- "We shall be going through each class of the property package in detail. Since there are not reactions occuring in the flowsheet we shall only write the Physical Parameter Block.\n",
+ "We shall be going through each class of the property package in detail. Since there are not reactions occurring in the flowsheet we shall only write the Physical Parameter Block.\n",
"\n",
"## 3.1 Physical Parameter Block\n",
"\n",
@@ -191,7 +191,7 @@
"\n",
"1. Define the input and output variables to the trained surrogate\n",
"2. Load the surrogate from the folder it is saved in, here it is saved in the folder called keras_surrogate (look at the keras_training_test.ipynb file) using the keras Surrogate API of IDAES package\n",
- "3. Define a `SurrogateBlock` and call the build_model method on the block with the input variables, output variables, model formulation and the loaded surrogate as the arguements. \n",
+ "3. Define a `SurrogateBlock` and call the build_model method on the block with the input variables, output variables, model formulation and the loaded surrogate as the arguments. \n",
"4. Define the constraints necessary for ensuring physical feasibility of the system like the mass balance and energy balance. Check for the state variables to be within the bounds. \n"
]
},
@@ -302,7 +302,7 @@
"3. `Return the state of the model` to where it originally started (with the exception of variable values). Any variable that was fixed or constraint that was deactivated during initialization should be unfixed or reactivated, so that the degrees of freedom are restored to what they were before the initialization began.\n",
"\n",
"\n",
- "Thus, we start with fixing the state variables. Here since enth_mol and entr_mol are a function of pressure and temperature, we do not fix them as fixing pressure and temperature would interm fix them. So, we check if a state variable if fixed or not, if it is fixed then we do not change them, if they are not fixed then we check for an initial guess from the `state_args`, if we get a value then we fix the varible with state_args, else we fix it with the value provided by the user. This should bring the degrees of freedom to 0. Here since we do not have any variable/constrained that we have unfixed/deactivated we can skip step 2 and move to step 3. We unfix the variables that were fixed in step 1 using the `release_state` function. "
+ "Thus, we start with fixing the state variables. Here since enth_mol and entr_mol are a function of pressure and temperature, we do not fix them as fixing pressure and temperature would inturn fix them. So, we check if a state variable if fixed or not, if it is fixed then we do not change them, if they are not fixed then we check for an initial guess from the `state_args`, if we get a value then we fix the variable with state_args, else we fix it with the value provided by the user. This should bring the degrees of freedom to 0. Here since we do not have any variable/constrained that we have unfixed/deactivated we can skip step 2 and move to step 3. We unfix the variables that were fixed in step 1 using the `release_state` function. "
]
},
{
@@ -333,7 +333,7 @@
"\n",
" * 0 = no output (default)\n",
" * 1 = return solver state for each step in routine\n",
- " * 2 = include solver output infomation (tee=True)\n",
+ " * 2 = include solver output information (tee=True)\n",
" state_vars_fixed: Flag to denote if state vars have already been\n",
" fixed.\n",
" - True - states have already been fixed by the\n",
@@ -344,18 +344,18 @@
" - False - states have not been fixed. The state\n",
" block will deal with fixing/unfixing.\n",
" optarg : solver options dictionary object (default=None)\n",
- " solver : str indicating whcih solver to use during\n",
+ " solver : str indicating which solver to use during\n",
" initialization (default = 'ipopt')\n",
" hold_state : flag indicating whether the initialization routine\n",
" should unfix any state variables fixed during\n",
" initialization (default=False).\n",
- " - True - states varaibles are not unfixed, and\n",
+ " - True - states variables are not unfixed, and\n",
" a dict of returned containing flags for\n",
" which states were fixed during\n",
" initialization.\n",
" - False - state variables are unfixed after\n",
" initialization by calling the\n",
- " relase_state method\n",
+ " release_state method\n",
"\n",
" Returns:\n",
" If hold_states is True, returns a dict containing flags for\n",
@@ -415,7 +415,7 @@
"\n",
" def release_state(blk, flags, outlvl=0):\n",
" '''\n",
- " Method to relase state variables fixed during initialisation.\n",
+ " Method to release state variables fixed during initialisation.\n",
"\n",
" Keyword Arguments:\n",
" flags : dict containing information of which state variables\n",
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/omlt/surrogate_embedding_usr.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/omlt/surrogate_embedding_usr.ipynb
index 40bbecf5..bdae332b 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/omlt/surrogate_embedding_usr.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/omlt/surrogate_embedding_usr.ipynb
@@ -33,9 +33,9 @@
"Updated: 2024-01-24\n",
"## 1. Integration of Surrogate into Custom Property Package\n",
"\n",
- "Here we shall see how to integrate the trained surrogate in the custom property package. One can read more about making a properties package from read the docs. To integrate the surrogate we first define the physical paramter block which will return the properties based on the state variables. State variables would be called from the State Block as Pyomo variables. We will define the surrogate input and output as pyomo variables as well. Once we have defined the variables in the state block then we define our surrogate block.\n",
+ "Here we shall see how to integrate the trained surrogate in the custom property package. One can read more about making a properties package from read the docs. To integrate the surrogate we first define the physical parameter block which will return the properties based on the state variables. State variables would be called from the State Block as Pyomo variables. We will define the surrogate input and output as pyomo variables as well. Once we have defined the variables in the state block then we define our surrogate block.\n",
"\n",
- "*NOTE:* For ease of explaination the property package is written in \".ipynb\" format, ideally it should be in a python script. Each class of this package is separated in different cell for the same reason, in practive all the classes in this notebook should be part of the same python script. This folder includes \"properties.py\" file which is how embedding file should look like. \n",
+ "*NOTE:* For ease of explanation the property package is written in \".ipynb\" format, ideally it should be in a python script. Each class of this package is separated in different cell for the same reason, in practice all the classes in this notebook should be part of the same python script. This folder includes \"properties.py\" file which is how embedding file should look like. \n",
"\n",
"### 1.1 Steps in Creating a Property Package\n",
"Creating a new property package can be broken down into the following steps, which will be demonstrated in the next part of this tutorial.\n",
@@ -106,7 +106,7 @@
"source": [
"# 3 Defining Classes\n",
"\n",
- "We shall be going through each class of the property package in detail. Since there are not reactions occuring in the flowsheet we shall only write the Physical Parameter Block.\n",
+ "We shall be going through each class of the property package in detail. Since there are not reactions occurring in the flowsheet we shall only write the Physical Parameter Block.\n",
"\n",
"## 3.1 Physical Parameter Block\n",
"\n",
@@ -189,7 +189,7 @@
"\n",
"1. Define the input and output variables to the trained surrogate\n",
"2. Load the surrogate from the folder it is saved in, here it is saved in the folder called keras_surrogate (look at the keras_training_usr.ipynb file) using the keras Surrogate API of IDAES package\n",
- "3. Define a `SurrogateBlock` and call the build_model method on the block with the input variables, output variables, model formulation and the loaded surrogate as the arguements. \n",
+ "3. Define a `SurrogateBlock` and call the build_model method on the block with the input variables, output variables, model formulation and the loaded surrogate as the arguments. \n",
"4. Define the constraints necessary for ensuring physical feasibility of the system like the mass balance and energy balance. Check for the state variables to be within the bounds. \n"
]
},
@@ -300,7 +300,7 @@
"3. `Return the state of the model` to where it originally started (with the exception of variable values). Any variable that was fixed or constraint that was deactivated during initialization should be unfixed or reactivated, so that the degrees of freedom are restored to what they were before the initialization began.\n",
"\n",
"\n",
- "Thus, we start with fixing the state variables. Here since enth_mol and entr_mol are a function of pressure and temperature, we do not fix them as fixing pressure and temperature would interm fix them. So, we check if a state variable if fixed or not, if it is fixed then we do not change them, if they are not fixed then we check for an initial guess from the `state_args`, if we get a value then we fix the varible with state_args, else we fix it with the value provided by the user. This should bring the degrees of freedom to 0. Here since we do not have any variable/constrained that we have unfixed/deactivated we can skip step 2 and move to step 3. We unfix the variables that were fixed in step 1 using the `release_state` function. "
+ "Thus, we start with fixing the state variables. Here since enth_mol and entr_mol are a function of pressure and temperature, we do not fix them as fixing pressure and temperature would inturn fix them. So, we check if a state variable if fixed or not, if it is fixed then we do not change them, if they are not fixed then we check for an initial guess from the `state_args`, if we get a value then we fix the variable with state_args, else we fix it with the value provided by the user. This should bring the degrees of freedom to 0. Here since we do not have any variable/constrained that we have unfixed/deactivated we can skip step 2 and move to step 3. We unfix the variables that were fixed in step 1 using the `release_state` function. "
]
},
{
@@ -331,7 +331,7 @@
"\n",
" * 0 = no output (default)\n",
" * 1 = return solver state for each step in routine\n",
- " * 2 = include solver output infomation (tee=True)\n",
+ " * 2 = include solver output information (tee=True)\n",
" state_vars_fixed: Flag to denote if state vars have already been\n",
" fixed.\n",
" - True - states have already been fixed by the\n",
@@ -342,18 +342,18 @@
" - False - states have not been fixed. The state\n",
" block will deal with fixing/unfixing.\n",
" optarg : solver options dictionary object (default=None)\n",
- " solver : str indicating whcih solver to use during\n",
+ " solver : str indicating which solver to use during\n",
" initialization (default = 'ipopt')\n",
" hold_state : flag indicating whether the initialization routine\n",
" should unfix any state variables fixed during\n",
" initialization (default=False).\n",
- " - True - states varaibles are not unfixed, and\n",
+ " - True - states variables are not unfixed, and\n",
" a dict of returned containing flags for\n",
" which states were fixed during\n",
" initialization.\n",
" - False - state variables are unfixed after\n",
" initialization by calling the\n",
- " relase_state method\n",
+ " release_state method\n",
"\n",
" Returns:\n",
" If hold_states is True, returns a dict containing flags for\n",
@@ -413,7 +413,7 @@
"\n",
" def release_state(blk, flags, outlvl=0):\n",
" '''\n",
- " Method to relase state variables fixed during initialisation.\n",
+ " Method to release state variables fixed during initialisation.\n",
"\n",
" Keyword Arguments:\n",
" flags : dict containing information of which state variables\n",
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/flowsheet_optimization.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/flowsheet_optimization.ipynb
index 9e79daba..a9b36bf2 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/flowsheet_optimization.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/flowsheet_optimization.ipynb
@@ -112,7 +112,7 @@
"source": [
"# 2. Constructing the flowsheet\n",
"\n",
- "To construct the flowsheet we need to define a ConcreteModel using pyomo and then add a FlowsheetBlock to the ConcreteModel. Here since we are focusing on the steady state process, we shall have the dynamic flag as False in the FlowsheetBlock. Next, we define the properties in the FlowsheetBlock that we imported from the properties.py file. Then start adding the unit models to the FlowsheetBlock with the suitable arguements, after which we connect them using Arcs as in the flowsheet above. \n",
+ "To construct the flowsheet we need to define a ConcreteModel using pyomo and then add a FlowsheetBlock to the ConcreteModel. Here since we are focusing on the steady state process, we shall have the dynamic flag as False in the FlowsheetBlock. Next, we define the properties in the FlowsheetBlock that we imported from the properties.py file. Then start adding the unit models to the FlowsheetBlock with the suitable arguments, after which we connect them using Arcs as in the flowsheet above. \n",
"\n",
"Once we have the connected flowsheet, we initialize individual unit models. Before initializing, we fix desired variables for the desired behavior of the unit model and then use `propagate_state` to pass on the state variables to next unit model in the flowsheet. After completely initializing the flowsheet, we convert the network to a mathematical form by using `network.expand_arcs` from the TransformationFactory and apply it on the flowsheet block. Then we call the solver and solve the flowsheet to calculate the total work in the process. "
]
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/flowsheet_optimization_doc.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/flowsheet_optimization_doc.ipynb
index 1be8ad23..a1eb955e 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/flowsheet_optimization_doc.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/flowsheet_optimization_doc.ipynb
@@ -110,7 +110,7 @@
"source": [
"# 2. Constructing the flowsheet\n",
"\n",
- "To construct the flowsheet we need to define a ConcreteModel using pyomo and then add a FlowsheetBlock to the ConcreteModel. Here since we are focusing on the steady state process, we shall have the dynamic flag as False in the FlowsheetBlock. Next, we define the properties in the FlowsheetBlock that we imported from the properties.py file. Then start adding the unit models to the FlowsheetBlock with the suitable arguements, after which we connect them using Arcs as in the flowsheet above. \n",
+ "To construct the flowsheet we need to define a ConcreteModel using pyomo and then add a FlowsheetBlock to the ConcreteModel. Here since we are focusing on the steady state process, we shall have the dynamic flag as False in the FlowsheetBlock. Next, we define the properties in the FlowsheetBlock that we imported from the properties.py file. Then start adding the unit models to the FlowsheetBlock with the suitable arguments, after which we connect them using Arcs as in the flowsheet above. \n",
"\n",
"Once we have the connected flowsheet, we initialize individual unit models. Before initializing, we fix desired variables for the desired behavior of the unit model and then use `propagate_state` to pass on the state variables to next unit model in the flowsheet. After completely initializing the flowsheet, we convert the network to a mathematical form by using `network.expand_arcs` from the TransformationFactory and apply it on the flowsheet block. Then we call the solver and solve the flowsheet to calculate the total work in the process. "
]
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/flowsheet_optimization_test.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/flowsheet_optimization_test.ipynb
index 1be8ad23..a1eb955e 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/flowsheet_optimization_test.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/flowsheet_optimization_test.ipynb
@@ -110,7 +110,7 @@
"source": [
"# 2. Constructing the flowsheet\n",
"\n",
- "To construct the flowsheet we need to define a ConcreteModel using pyomo and then add a FlowsheetBlock to the ConcreteModel. Here since we are focusing on the steady state process, we shall have the dynamic flag as False in the FlowsheetBlock. Next, we define the properties in the FlowsheetBlock that we imported from the properties.py file. Then start adding the unit models to the FlowsheetBlock with the suitable arguements, after which we connect them using Arcs as in the flowsheet above. \n",
+ "To construct the flowsheet we need to define a ConcreteModel using pyomo and then add a FlowsheetBlock to the ConcreteModel. Here since we are focusing on the steady state process, we shall have the dynamic flag as False in the FlowsheetBlock. Next, we define the properties in the FlowsheetBlock that we imported from the properties.py file. Then start adding the unit models to the FlowsheetBlock with the suitable arguments, after which we connect them using Arcs as in the flowsheet above. \n",
"\n",
"Once we have the connected flowsheet, we initialize individual unit models. Before initializing, we fix desired variables for the desired behavior of the unit model and then use `propagate_state` to pass on the state variables to next unit model in the flowsheet. After completely initializing the flowsheet, we convert the network to a mathematical form by using `network.expand_arcs` from the TransformationFactory and apply it on the flowsheet block. Then we call the solver and solve the flowsheet to calculate the total work in the process. "
]
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/flowsheet_optimization_usr.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/flowsheet_optimization_usr.ipynb
index 1be8ad23..a1eb955e 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/flowsheet_optimization_usr.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/flowsheet_optimization_usr.ipynb
@@ -110,7 +110,7 @@
"source": [
"# 2. Constructing the flowsheet\n",
"\n",
- "To construct the flowsheet we need to define a ConcreteModel using pyomo and then add a FlowsheetBlock to the ConcreteModel. Here since we are focusing on the steady state process, we shall have the dynamic flag as False in the FlowsheetBlock. Next, we define the properties in the FlowsheetBlock that we imported from the properties.py file. Then start adding the unit models to the FlowsheetBlock with the suitable arguements, after which we connect them using Arcs as in the flowsheet above. \n",
+ "To construct the flowsheet we need to define a ConcreteModel using pyomo and then add a FlowsheetBlock to the ConcreteModel. Here since we are focusing on the steady state process, we shall have the dynamic flag as False in the FlowsheetBlock. Next, we define the properties in the FlowsheetBlock that we imported from the properties.py file. Then start adding the unit models to the FlowsheetBlock with the suitable arguments, after which we connect them using Arcs as in the flowsheet above. \n",
"\n",
"Once we have the connected flowsheet, we initialize individual unit models. Before initializing, we fix desired variables for the desired behavior of the unit model and then use `propagate_state` to pass on the state variables to next unit model in the flowsheet. After completely initializing the flowsheet, we convert the network to a mathematical form by using `network.expand_arcs` from the TransformationFactory and apply it on the flowsheet block. Then we call the solver and solve the flowsheet to calculate the total work in the process. "
]
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/properties.py b/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/properties.py
index e8c8528f..af06a238 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/properties.py
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/properties.py
@@ -119,7 +119,7 @@ def initialize(blk, state_args=None, hold_state=False, outlvl=1,
* 0 = no output (default)
* 1 = return solver state for each step in routine
- * 2 = include solver output infomation (tee=True)
+ * 2 = include solver output information (tee=True)
state_vars_fixed: Flag to denote if state vars have already been
fixed.
- True - states have already been fixed by the
@@ -130,18 +130,18 @@ def initialize(blk, state_args=None, hold_state=False, outlvl=1,
- False - states have not been fixed. The state
block will deal with fixing/unfixing.
optarg : solver options dictionary object (default=None)
- solver : str indicating whcih solver to use during
+ solver : str indicating which 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).
- - True - states varaibles are not unfixed, and
+ - 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
- relase_state method
+ release_state method
Returns:
If hold_states is True, returns a dict containing flags for
@@ -201,7 +201,7 @@ def initialize(blk, state_args=None, hold_state=False, outlvl=1,
def release_state(blk, flags, outlvl=0):
'''
- Method to relase state variables fixed during initialisation.
+ Method to release state variables fixed during initialisation.
Keyword Arguments:
flags : dict containing information of which state variables
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/pysmo_training.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/pysmo_training.ipynb
index d48df4a0..c9baee3f 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/pysmo_training.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/pysmo_training.ipynb
@@ -41,7 +41,7 @@
"### 1.1 Need for ML Surrogates\n",
"\n",
"The properties predicted by the surrogate are enthalpy and entropy of the S-CO2 based on the \n",
- "pressure and temperature of the system. The analytical equation of getting the enthalpy and entropy from pressure and temperature are in the differential form and would make the problem a DAE system. To counter this problem and keep the problem algebric, we will use the ML surrogates and relate enthalpy and entropy with the pressure and temperature as an algebric equation.\n",
+ "pressure and temperature of the system. The analytical equation of getting the enthalpy and entropy from pressure and temperature are in the differential form and would make the problem a DAE system. To counter this problem and keep the problem algebraic, we will use the ML surrogates and relate enthalpy and entropy with the pressure and temperature as an algebraic equation.\n",
"\n",
"### 1.2 Supercritical CO2 cycle process\n",
"\n",
@@ -117,7 +117,7 @@
"\n",
"In this section, we read the dataset from the CSV file located in this directory. 500 data points were simulated for S-CO2 physical properties using REFPROP package. This example is trained on the entire dataset because neural network can overfit on smaller dataset. The data is separated using an 80/20 split into training and validation data using the IDAES split_training_validation() method.\n",
"\n",
- "We rename the column headers because they contained \".\", which may cause errors while reading the column names in subsquent code, thus as a good practice we change them to the variable names to be used in the property package. Further, the input variables are **pressure**, **temperature** , while the output variables are **enth_mol**, **entr_mol**, hence we create two new dataframes for the input and output variables. "
+ "We rename the column headers because they contained \".\", which may cause errors while reading the column names in subsequent code, thus as a good practice we change them to the variable names to be used in the property package. Further, the input variables are **pressure**, **temperature** , while the output variables are **enth_mol**, **entr_mol**, hence we create two new dataframes for the input and output variables. "
]
},
{
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/pysmo_training_doc.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/pysmo_training_doc.ipynb
index d85593b8..f28f5e92 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/pysmo_training_doc.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/pysmo_training_doc.ipynb
@@ -41,7 +41,7 @@
"### 1.1 Need for ML Surrogates\n",
"\n",
"The properties predicted by the surrogate are enthalpy and entropy of the S-CO2 based on the \n",
- "pressure and temperature of the system. The analytical equation of getting the enthalpy and entropy from pressure and temperature are in the differential form and would make the problem a DAE system. To counter this problem and keep the problem algebric, we will use the ML surrogates and relate enthalpy and entropy with the pressure and temperature as an algebric equation.\n",
+ "pressure and temperature of the system. The analytical equation of getting the enthalpy and entropy from pressure and temperature are in the differential form and would make the problem a DAE system. To counter this problem and keep the problem algebraic, we will use the ML surrogates and relate enthalpy and entropy with the pressure and temperature as an algebraic equation.\n",
"\n",
"### 1.2 Supercritical CO2 cycle process\n",
"\n",
@@ -117,7 +117,7 @@
"\n",
"In this section, we read the dataset from the CSV file located in this directory. 500 data points were simulated for S-CO2 physical properties using REFPROP package. This example is trained on the entire dataset because neural network can overfit on smaller dataset. The data is separated using an 80/20 split into training and validation data using the IDAES split_training_validation() method.\n",
"\n",
- "We rename the column headers because they contained \".\", which may cause errors while reading the column names in subsquent code, thus as a good practice we change them to the variable names to be used in the property package. Further, the input variables are **pressure**, **temperature** , while the output variables are **enth_mol**, **entr_mol**, hence we create two new dataframes for the input and output variables. "
+ "We rename the column headers because they contained \".\", which may cause errors while reading the column names in subsequent code, thus as a good practice we change them to the variable names to be used in the property package. Further, the input variables are **pressure**, **temperature** , while the output variables are **enth_mol**, **entr_mol**, hence we create two new dataframes for the input and output variables. "
]
},
{
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/pysmo_training_test.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/pysmo_training_test.ipynb
index 13044384..7ecb22fe 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/pysmo_training_test.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/pysmo_training_test.ipynb
@@ -41,7 +41,7 @@
"### 1.1 Need for ML Surrogates\n",
"\n",
"The properties predicted by the surrogate are enthalpy and entropy of the S-CO2 based on the \n",
- "pressure and temperature of the system. The analytical equation of getting the enthalpy and entropy from pressure and temperature are in the differential form and would make the problem a DAE system. To counter this problem and keep the problem algebric, we will use the ML surrogates and relate enthalpy and entropy with the pressure and temperature as an algebric equation.\n",
+ "pressure and temperature of the system. The analytical equation of getting the enthalpy and entropy from pressure and temperature are in the differential form and would make the problem a DAE system. To counter this problem and keep the problem algebraic, we will use the ML surrogates and relate enthalpy and entropy with the pressure and temperature as an algebraic equation.\n",
"\n",
"### 1.2 Supercritical CO2 cycle process\n",
"\n",
@@ -117,7 +117,7 @@
"\n",
"In this section, we read the dataset from the CSV file located in this directory. 500 data points were simulated for S-CO2 physical properties using REFPROP package. This example is trained on the entire dataset because neural network can overfit on smaller dataset. The data is separated using an 80/20 split into training and validation data using the IDAES split_training_validation() method.\n",
"\n",
- "We rename the column headers because they contained \".\", which may cause errors while reading the column names in subsquent code, thus as a good practice we change them to the variable names to be used in the property package. Further, the input variables are **pressure**, **temperature** , while the output variables are **enth_mol**, **entr_mol**, hence we create two new dataframes for the input and output variables. "
+ "We rename the column headers because they contained \".\", which may cause errors while reading the column names in subsequent code, thus as a good practice we change them to the variable names to be used in the property package. Further, the input variables are **pressure**, **temperature** , while the output variables are **enth_mol**, **entr_mol**, hence we create two new dataframes for the input and output variables. "
]
},
{
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/pysmo_training_usr.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/pysmo_training_usr.ipynb
index ed8d224c..46e17535 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/pysmo_training_usr.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/pysmo_training_usr.ipynb
@@ -41,7 +41,7 @@
"### 1.1 Need for ML Surrogates\n",
"\n",
"The properties predicted by the surrogate are enthalpy and entropy of the S-CO2 based on the \n",
- "pressure and temperature of the system. The analytical equation of getting the enthalpy and entropy from pressure and temperature are in the differential form and would make the problem a DAE system. To counter this problem and keep the problem algebric, we will use the ML surrogates and relate enthalpy and entropy with the pressure and temperature as an algebric equation.\n",
+ "pressure and temperature of the system. The analytical equation of getting the enthalpy and entropy from pressure and temperature are in the differential form and would make the problem a DAE system. To counter this problem and keep the problem algebraic, we will use the ML surrogates and relate enthalpy and entropy with the pressure and temperature as an algebraic equation.\n",
"\n",
"### 1.2 Supercritical CO2 cycle process\n",
"\n",
@@ -117,7 +117,7 @@
"\n",
"In this section, we read the dataset from the CSV file located in this directory. 500 data points were simulated for S-CO2 physical properties using REFPROP package. This example is trained on the entire dataset because neural network can overfit on smaller dataset. The data is separated using an 80/20 split into training and validation data using the IDAES split_training_validation() method.\n",
"\n",
- "We rename the column headers because they contained \".\", which may cause errors while reading the column names in subsquent code, thus as a good practice we change them to the variable names to be used in the property package. Further, the input variables are **pressure**, **temperature** , while the output variables are **enth_mol**, **entr_mol**, hence we create two new dataframes for the input and output variables. "
+ "We rename the column headers because they contained \".\", which may cause errors while reading the column names in subsequent code, thus as a good practice we change them to the variable names to be used in the property package. Further, the input variables are **pressure**, **temperature** , while the output variables are **enth_mol**, **entr_mol**, hence we create two new dataframes for the input and output variables. "
]
},
{
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/surrogate_embedding.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/surrogate_embedding.ipynb
index a2b04ccc..acf8997a 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/surrogate_embedding.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/surrogate_embedding.ipynb
@@ -32,9 +32,9 @@
"Updated: 2024-01-24\n",
"## 1. Integration of Surrogate into Custom Property Package\n",
"\n",
- "Here we shall see how to integrate the trained surrogate in the custom property package. One can read more about making a properties package from read the docs. To integrate the surrogate we first define the physical paramter block which will return the properties based on the state variables. State variables would be called from the State Block as Pyomo variables. We will define the surrogate input and output as pyomo variables as well. Once we have defined the variables in the state block then we define our surrogate block.\n",
+ "Here we shall see how to integrate the trained surrogate in the custom property package. One can read more about making a properties package from read the docs. To integrate the surrogate we first define the physical parameter block which will return the properties based on the state variables. State variables would be called from the State Block as Pyomo variables. We will define the surrogate input and output as pyomo variables as well. Once we have defined the variables in the state block then we define our surrogate block.\n",
"\n",
- "*NOTE:* For ease of explaination the property package is written in \".ipynb\" format, ideally it should be in a python script. Each class of this package is separated in different cell for the same reason, in practive all the classes in this notebook should be part of the same python script. This folder includes \"properties.py\" file which is how embedding file should look like. \n",
+ "*NOTE:* For ease of explanation the property package is written in \".ipynb\" format, ideally it should be in a python script. Each class of this package is separated in different cell for the same reason, in practice all the classes in this notebook should be part of the same python script. This folder includes \"properties.py\" file which is how embedding file should look like. \n",
"\n",
"### 1.1 Steps in Creating a Property Package\n",
"Creating a new property package can be broken down into the following steps, which will be demonstrated in the next part of this tutorial.\n",
@@ -105,7 +105,7 @@
"source": [
"# 3 Defining Classes\n",
"\n",
- "We shall be going through each class of the property package in detail. Since there are not reactions occuring in the flowsheet we shall only write the Physical Parameter Block.\n",
+ "We shall be going through each class of the property package in detail. Since there are not reactions occurring in the flowsheet we shall only write the Physical Parameter Block.\n",
"\n",
"## 3.1 Physical Parameter Block\n",
"\n",
@@ -189,7 +189,7 @@
"\n",
"1. Define the input and output variables to the trained surrogate\n",
"2. Load the surrogate from the folder it is saved in, here it is saved in the folder called pysmo_surrogate (look at the pysmo_training.ipynb file) using the PySMO Surrogate API of IDAES package\n",
- "3. Define a `SurrogateBlock` and call the build_model method on the block with the input variables, output variables, model formulation and the loaded surrogate as the arguements. \n",
+ "3. Define a `SurrogateBlock` and call the build_model method on the block with the input variables, output variables, model formulation and the loaded surrogate as the arguments. \n",
"4. Define the constraints necessary for ensuring physical feasibility of the system like the mass balance and energy balance. Check for the state variables to be within the bounds. \n"
]
},
@@ -303,7 +303,7 @@
"3. `Return the state of the model` to where it originally started (with the exception of variable values). Any variable that was fixed or constraint that was deactivated during initialization should be unfixed or reactivated, so that the degrees of freedom are restored to what they were before the initialization began.\n",
"\n",
"\n",
- "Thus, we start with fixing the state variables. Here since enth_mol and entr_mol are a function of pressure and temperature, we do not fix them as fixing pressure and temperature would interm fix them. So, we check if a state variable if fixed or not, if it is fixed then we do not change them, if they are not fixed then we check for an initial guess from the `state_args`, if we get a value then we fix the varible with state_args, else we fix it with the value provided by the user. This should bring the degrees of freedom to 0. Here since we do not have any variable/constrained that we have unfixed/deactivated we can skip step 2 and move to step 3. We unfix the variables that were fixed in step 1 using the `release_state` function. "
+ "Thus, we start with fixing the state variables. Here since enth_mol and entr_mol are a function of pressure and temperature, we do not fix them as fixing pressure and temperature would define them. So, we check if a state variable if fixed or not, if it is fixed then we do not change them, if they are not fixed then we check for an initial guess from the `state_args`, if we get a value then we fix the variable with state_args, else we fix it with the value provided by the user. This should bring the degrees of freedom to 0. Here since we do not have any variable/constrained that we have unfixed/deactivated we can skip step 2 and move to step 3. We unfix the variables that were fixed in step 1 using the `release_state` function. "
]
},
{
@@ -334,7 +334,7 @@
"\n",
" * 0 = no output (default)\n",
" * 1 = return solver state for each step in routine\n",
- " * 2 = include solver output infomation (tee=True)\n",
+ " * 2 = include solver output information (tee=True)\n",
" state_vars_fixed: Flag to denote if state vars have already been\n",
" fixed.\n",
" - True - states have already been fixed by the\n",
@@ -345,18 +345,18 @@
" - False - states have not been fixed. The state\n",
" block will deal with fixing/unfixing.\n",
" optarg : solver options dictionary object (default=None)\n",
- " solver : str indicating whcih solver to use during\n",
+ " solver : str indicating which solver to use during\n",
" initialization (default = 'ipopt')\n",
" hold_state : flag indicating whether the initialization routine\n",
" should unfix any state variables fixed during\n",
" initialization (default=False).\n",
- " - True - states varaibles are not unfixed, and\n",
+ " - True - states variables are not unfixed, and\n",
" a dict of returned containing flags for\n",
" which states were fixed during\n",
" initialization.\n",
" - False - state variables are unfixed after\n",
" initialization by calling the\n",
- " relase_state method\n",
+ " release_state method\n",
"\n",
" Returns:\n",
" If hold_states is True, returns a dict containing flags for\n",
@@ -416,7 +416,7 @@
"\n",
" def release_state(blk, flags, outlvl=0):\n",
" '''\n",
- " Method to relase state variables fixed during initialisation.\n",
+ " Method to release state variables fixed during initialisation.\n",
"\n",
" Keyword Arguments:\n",
" flags : dict containing information of which state variables\n",
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/surrogate_embedding_doc.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/surrogate_embedding_doc.ipynb
index ec1968c1..a2ca0c6c 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/surrogate_embedding_doc.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/surrogate_embedding_doc.ipynb
@@ -32,9 +32,9 @@
"Updated: 2024-01-24\n",
"## 1. Integration of Surrogate into Custom Property Package\n",
"\n",
- "Here we shall see how to integrate the trained surrogate in the custom property package. One can read more about making a properties package from read the docs. To integrate the surrogate we first define the physical paramter block which will return the properties based on the state variables. State variables would be called from the State Block as Pyomo variables. We will define the surrogate input and output as pyomo variables as well. Once we have defined the variables in the state block then we define our surrogate block.\n",
+ "Here we shall see how to integrate the trained surrogate in the custom property package. One can read more about making a properties package from read the docs. To integrate the surrogate we first define the physical parameter block which will return the properties based on the state variables. State variables would be called from the State Block as Pyomo variables. We will define the surrogate input and output as pyomo variables as well. Once we have defined the variables in the state block then we define our surrogate block.\n",
"\n",
- "*NOTE:* For ease of explaination the property package is written in \".ipynb\" format, ideally it should be in a python script. Each class of this package is separated in different cell for the same reason, in practive all the classes in this notebook should be part of the same python script. This folder includes \"properties.py\" file which is how embedding file should look like. \n",
+ "*NOTE:* For ease of explanation the property package is written in \".ipynb\" format, ideally it should be in a python script. Each class of this package is separated in different cell for the same reason, in practice all the classes in this notebook should be part of the same python script. This folder includes \"properties.py\" file which is how embedding file should look like. \n",
"\n",
"### 1.1 Steps in Creating a Property Package\n",
"Creating a new property package can be broken down into the following steps, which will be demonstrated in the next part of this tutorial.\n",
@@ -105,7 +105,7 @@
"source": [
"# 3 Defining Classes\n",
"\n",
- "We shall be going through each class of the property package in detail. Since there are not reactions occuring in the flowsheet we shall only write the Physical Parameter Block.\n",
+ "We shall be going through each class of the property package in detail. Since there are not reactions occurring in the flowsheet we shall only write the Physical Parameter Block.\n",
"\n",
"## 3.1 Physical Parameter Block\n",
"\n",
@@ -189,7 +189,7 @@
"\n",
"1. Define the input and output variables to the trained surrogate\n",
"2. Load the surrogate from the folder it is saved in, here it is saved in the folder called pysmo_surrogate (look at the pysmo_training_doc.md file) using the PySMO Surrogate API of IDAES package\n",
- "3. Define a `SurrogateBlock` and call the build_model method on the block with the input variables, output variables, model formulation and the loaded surrogate as the arguements. \n",
+ "3. Define a `SurrogateBlock` and call the build_model method on the block with the input variables, output variables, model formulation and the loaded surrogate as the arguments. \n",
"4. Define the constraints necessary for ensuring physical feasibility of the system like the mass balance and energy balance. Check for the state variables to be within the bounds. \n"
]
},
@@ -303,7 +303,7 @@
"3. `Return the state of the model` to where it originally started (with the exception of variable values). Any variable that was fixed or constraint that was deactivated during initialization should be unfixed or reactivated, so that the degrees of freedom are restored to what they were before the initialization began.\n",
"\n",
"\n",
- "Thus, we start with fixing the state variables. Here since enth_mol and entr_mol are a function of pressure and temperature, we do not fix them as fixing pressure and temperature would interm fix them. So, we check if a state variable if fixed or not, if it is fixed then we do not change them, if they are not fixed then we check for an initial guess from the `state_args`, if we get a value then we fix the varible with state_args, else we fix it with the value provided by the user. This should bring the degrees of freedom to 0. Here since we do not have any variable/constrained that we have unfixed/deactivated we can skip step 2 and move to step 3. We unfix the variables that were fixed in step 1 using the `release_state` function. "
+ "Thus, we start with fixing the state variables. Here since enth_mol and entr_mol are a function of pressure and temperature, we do not fix them as fixing pressure and temperature would define them. So, we check if a state variable if fixed or not, if it is fixed then we do not change them, if they are not fixed then we check for an initial guess from the `state_args`, if we get a value then we fix the variable with state_args, else we fix it with the value provided by the user. This should bring the degrees of freedom to 0. Here since we do not have any variable/constrained that we have unfixed/deactivated we can skip step 2 and move to step 3. We unfix the variables that were fixed in step 1 using the `release_state` function. "
]
},
{
@@ -334,7 +334,7 @@
"\n",
" * 0 = no output (default)\n",
" * 1 = return solver state for each step in routine\n",
- " * 2 = include solver output infomation (tee=True)\n",
+ " * 2 = include solver output information (tee=True)\n",
" state_vars_fixed: Flag to denote if state vars have already been\n",
" fixed.\n",
" - True - states have already been fixed by the\n",
@@ -345,18 +345,18 @@
" - False - states have not been fixed. The state\n",
" block will deal with fixing/unfixing.\n",
" optarg : solver options dictionary object (default=None)\n",
- " solver : str indicating whcih solver to use during\n",
+ " solver : str indicating which solver to use during\n",
" initialization (default = 'ipopt')\n",
" hold_state : flag indicating whether the initialization routine\n",
" should unfix any state variables fixed during\n",
" initialization (default=False).\n",
- " - True - states varaibles are not unfixed, and\n",
+ " - True - states variables are not unfixed, and\n",
" a dict of returned containing flags for\n",
" which states were fixed during\n",
" initialization.\n",
" - False - state variables are unfixed after\n",
" initialization by calling the\n",
- " relase_state method\n",
+ " release_state method\n",
"\n",
" Returns:\n",
" If hold_states is True, returns a dict containing flags for\n",
@@ -416,7 +416,7 @@
"\n",
" def release_state(blk, flags, outlvl=0):\n",
" '''\n",
- " Method to relase state variables fixed during initialisation.\n",
+ " Method to release state variables fixed during initialisation.\n",
"\n",
" Keyword Arguments:\n",
" flags : dict containing information of which state variables\n",
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/surrogate_embedding_test.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/surrogate_embedding_test.ipynb
index 054e2f66..08681a4a 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/surrogate_embedding_test.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/surrogate_embedding_test.ipynb
@@ -32,9 +32,9 @@
"Updated: 2024-01-24\n",
"## 1. Integration of Surrogate into Custom Property Package\n",
"\n",
- "Here we shall see how to integrate the trained surrogate in the custom property package. One can read more about making a properties package from read the docs. To integrate the surrogate we first define the physical paramter block which will return the properties based on the state variables. State variables would be called from the State Block as Pyomo variables. We will define the surrogate input and output as pyomo variables as well. Once we have defined the variables in the state block then we define our surrogate block.\n",
+ "Here we shall see how to integrate the trained surrogate in the custom property package. One can read more about making a properties package from read the docs. To integrate the surrogate we first define the physical parameter block which will return the properties based on the state variables. State variables would be called from the State Block as Pyomo variables. We will define the surrogate input and output as pyomo variables as well. Once we have defined the variables in the state block then we define our surrogate block.\n",
"\n",
- "*NOTE:* For ease of explaination the property package is written in \".ipynb\" format, ideally it should be in a python script. Each class of this package is separated in different cell for the same reason, in practive all the classes in this notebook should be part of the same python script. This folder includes \"properties.py\" file which is how embedding file should look like. \n",
+ "*NOTE:* For ease of explanation the property package is written in \".ipynb\" format, ideally it should be in a python script. Each class of this package is separated in different cell for the same reason, in practice all the classes in this notebook should be part of the same python script. This folder includes \"properties.py\" file which is how embedding file should look like. \n",
"\n",
"### 1.1 Steps in Creating a Property Package\n",
"Creating a new property package can be broken down into the following steps, which will be demonstrated in the next part of this tutorial.\n",
@@ -107,7 +107,7 @@
"source": [
"# 3 Defining Classes\n",
"\n",
- "We shall be going through each class of the property package in detail. Since there are not reactions occuring in the flowsheet we shall only write the Physical Parameter Block.\n",
+ "We shall be going through each class of the property package in detail. Since there are not reactions occurring in the flowsheet we shall only write the Physical Parameter Block.\n",
"\n",
"## 3.1 Physical Parameter Block\n",
"\n",
@@ -191,7 +191,7 @@
"\n",
"1. Define the input and output variables to the trained surrogate\n",
"2. Load the surrogate from the folder it is saved in, here it is saved in the folder called pysmo_surrogate (look at the pysmo_training_test.ipynb file) using the PySMO Surrogate API of IDAES package\n",
- "3. Define a `SurrogateBlock` and call the build_model method on the block with the input variables, output variables, model formulation and the loaded surrogate as the arguements. \n",
+ "3. Define a `SurrogateBlock` and call the build_model method on the block with the input variables, output variables, model formulation and the loaded surrogate as the arguments. \n",
"4. Define the constraints necessary for ensuring physical feasibility of the system like the mass balance and energy balance. Check for the state variables to be within the bounds. \n"
]
},
@@ -305,7 +305,7 @@
"3. `Return the state of the model` to where it originally started (with the exception of variable values). Any variable that was fixed or constraint that was deactivated during initialization should be unfixed or reactivated, so that the degrees of freedom are restored to what they were before the initialization began.\n",
"\n",
"\n",
- "Thus, we start with fixing the state variables. Here since enth_mol and entr_mol are a function of pressure and temperature, we do not fix them as fixing pressure and temperature would interm fix them. So, we check if a state variable if fixed or not, if it is fixed then we do not change them, if they are not fixed then we check for an initial guess from the `state_args`, if we get a value then we fix the varible with state_args, else we fix it with the value provided by the user. This should bring the degrees of freedom to 0. Here since we do not have any variable/constrained that we have unfixed/deactivated we can skip step 2 and move to step 3. We unfix the variables that were fixed in step 1 using the `release_state` function. "
+ "Thus, we start with fixing the state variables. Here since enth_mol and entr_mol are a function of pressure and temperature, we do not fix them as fixing pressure and temperature would define them. So, we check if a state variable if fixed or not, if it is fixed then we do not change them, if they are not fixed then we check for an initial guess from the `state_args`, if we get a value then we fix the variable with state_args, else we fix it with the value provided by the user. This should bring the degrees of freedom to 0. Here since we do not have any variable/constrained that we have unfixed/deactivated we can skip step 2 and move to step 3. We unfix the variables that were fixed in step 1 using the `release_state` function. "
]
},
{
@@ -336,7 +336,7 @@
"\n",
" * 0 = no output (default)\n",
" * 1 = return solver state for each step in routine\n",
- " * 2 = include solver output infomation (tee=True)\n",
+ " * 2 = include solver output information (tee=True)\n",
" state_vars_fixed: Flag to denote if state vars have already been\n",
" fixed.\n",
" - True - states have already been fixed by the\n",
@@ -347,18 +347,18 @@
" - False - states have not been fixed. The state\n",
" block will deal with fixing/unfixing.\n",
" optarg : solver options dictionary object (default=None)\n",
- " solver : str indicating whcih solver to use during\n",
+ " solver : str indicating which solver to use during\n",
" initialization (default = 'ipopt')\n",
" hold_state : flag indicating whether the initialization routine\n",
" should unfix any state variables fixed during\n",
" initialization (default=False).\n",
- " - True - states varaibles are not unfixed, and\n",
+ " - True - states variables are not unfixed, and\n",
" a dict of returned containing flags for\n",
" which states were fixed during\n",
" initialization.\n",
" - False - state variables are unfixed after\n",
" initialization by calling the\n",
- " relase_state method\n",
+ " release_state method\n",
"\n",
" Returns:\n",
" If hold_states is True, returns a dict containing flags for\n",
@@ -418,7 +418,7 @@
"\n",
" def release_state(blk, flags, outlvl=0):\n",
" '''\n",
- " Method to relase state variables fixed during initialisation.\n",
+ " Method to release state variables fixed during initialisation.\n",
"\n",
" Keyword Arguments:\n",
" flags : dict containing information of which state variables\n",
diff --git a/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/surrogate_embedding_usr.ipynb b/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/surrogate_embedding_usr.ipynb
index d67ce305..8ad3ae88 100644
--- a/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/surrogate_embedding_usr.ipynb
+++ b/idaes_examples/notebooks/docs/surrogates/sco2/pysmo/surrogate_embedding_usr.ipynb
@@ -32,9 +32,9 @@
"Updated: 2024-01-24\n",
"## 1. Integration of Surrogate into Custom Property Package\n",
"\n",
- "Here we shall see how to integrate the trained surrogate in the custom property package. One can read more about making a properties package from read the docs. To integrate the surrogate we first define the physical paramter block which will return the properties based on the state variables. State variables would be called from the State Block as Pyomo variables. We will define the surrogate input and output as pyomo variables as well. Once we have defined the variables in the state block then we define our surrogate block.\n",
+ "Here we shall see how to integrate the trained surrogate in the custom property package. One can read more about making a properties package from read the docs. To integrate the surrogate we first define the physical parameter block which will return the properties based on the state variables. State variables would be called from the State Block as Pyomo variables. We will define the surrogate input and output as pyomo variables as well. Once we have defined the variables in the state block then we define our surrogate block.\n",
"\n",
- "*NOTE:* For ease of explaination the property package is written in \".ipynb\" format, ideally it should be in a python script. Each class of this package is separated in different cell for the same reason, in practive all the classes in this notebook should be part of the same python script. This folder includes \"properties.py\" file which is how embedding file should look like. \n",
+ "*NOTE:* For ease of explanation the property package is written in \".ipynb\" format, ideally it should be in a python script. Each class of this package is separated in different cell for the same reason, in practice all the classes in this notebook should be part of the same python script. This folder includes \"properties.py\" file which is how embedding file should look like. \n",
"\n",
"### 1.1 Steps in Creating a Property Package\n",
"Creating a new property package can be broken down into the following steps, which will be demonstrated in the next part of this tutorial.\n",
@@ -105,7 +105,7 @@
"source": [
"# 3 Defining Classes\n",
"\n",
- "We shall be going through each class of the property package in detail. Since there are not reactions occuring in the flowsheet we shall only write the Physical Parameter Block.\n",
+ "We shall be going through each class of the property package in detail. Since there are not reactions occurring in the flowsheet we shall only write the Physical Parameter Block.\n",
"\n",
"## 3.1 Physical Parameter Block\n",
"\n",
@@ -189,7 +189,7 @@
"\n",
"1. Define the input and output variables to the trained surrogate\n",
"2. Load the surrogate from the folder it is saved in, here it is saved in the folder called pysmo_surrogate (look at the pysmo_training_usr.ipynb file) using the PySMO Surrogate API of IDAES package\n",
- "3. Define a `SurrogateBlock` and call the build_model method on the block with the input variables, output variables, model formulation and the loaded surrogate as the arguements. \n",
+ "3. Define a `SurrogateBlock` and call the build_model method on the block with the input variables, output variables, model formulation and the loaded surrogate as the arguments. \n",
"4. Define the constraints necessary for ensuring physical feasibility of the system like the mass balance and energy balance. Check for the state variables to be within the bounds. \n"
]
},
@@ -303,7 +303,7 @@
"3. `Return the state of the model` to where it originally started (with the exception of variable values). Any variable that was fixed or constraint that was deactivated during initialization should be unfixed or reactivated, so that the degrees of freedom are restored to what they were before the initialization began.\n",
"\n",
"\n",
- "Thus, we start with fixing the state variables. Here since enth_mol and entr_mol are a function of pressure and temperature, we do not fix them as fixing pressure and temperature would interm fix them. So, we check if a state variable if fixed or not, if it is fixed then we do not change them, if they are not fixed then we check for an initial guess from the `state_args`, if we get a value then we fix the varible with state_args, else we fix it with the value provided by the user. This should bring the degrees of freedom to 0. Here since we do not have any variable/constrained that we have unfixed/deactivated we can skip step 2 and move to step 3. We unfix the variables that were fixed in step 1 using the `release_state` function. "
+ "Thus, we start with fixing the state variables. Here since enth_mol and entr_mol are a function of pressure and temperature, we do not fix them as fixing pressure and temperature would define them. So, we check if a state variable if fixed or not, if it is fixed then we do not change them, if they are not fixed then we check for an initial guess from the `state_args`, if we get a value then we fix the variable with state_args, else we fix it with the value provided by the user. This should bring the degrees of freedom to 0. Here since we do not have any variable/constrained that we have unfixed/deactivated we can skip step 2 and move to step 3. We unfix the variables that were fixed in step 1 using the `release_state` function. "
]
},
{
@@ -334,7 +334,7 @@
"\n",
" * 0 = no output (default)\n",
" * 1 = return solver state for each step in routine\n",
- " * 2 = include solver output infomation (tee=True)\n",
+ " * 2 = include solver output information (tee=True)\n",
" state_vars_fixed: Flag to denote if state vars have already been\n",
" fixed.\n",
" - True - states have already been fixed by the\n",
@@ -345,18 +345,18 @@
" - False - states have not been fixed. The state\n",
" block will deal with fixing/unfixing.\n",
" optarg : solver options dictionary object (default=None)\n",
- " solver : str indicating whcih solver to use during\n",
+ " solver : str indicating which solver to use during\n",
" initialization (default = 'ipopt')\n",
" hold_state : flag indicating whether the initialization routine\n",
" should unfix any state variables fixed during\n",
" initialization (default=False).\n",
- " - True - states varaibles are not unfixed, and\n",
+ " - True - states variables are not unfixed, and\n",
" a dict of returned containing flags for\n",
" which states were fixed during\n",
" initialization.\n",
" - False - state variables are unfixed after\n",
" initialization by calling the\n",
- " relase_state method\n",
+ " release_state method\n",
"\n",
" Returns:\n",
" If hold_states is True, returns a dict containing flags for\n",
@@ -416,7 +416,7 @@
"\n",
" def release_state(blk, flags, outlvl=0):\n",
" '''\n",
- " Method to relase state variables fixed during initialisation.\n",
+ " Method to release state variables fixed during initialisation.\n",
"\n",
" Keyword Arguments:\n",
" flags : dict containing information of which state variables\n",
diff --git a/idaes_examples/notebooks/docs/tut/core/flash_unit.ipynb b/idaes_examples/notebooks/docs/tut/core/flash_unit.ipynb
index 97a4fbe6..6dc88109 100644
--- a/idaes_examples/notebooks/docs/tut/core/flash_unit.ipynb
+++ b/idaes_examples/notebooks/docs/tut/core/flash_unit.ipynb
@@ -514,7 +514,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "Now that the model has been defined and intialized, we can solve the model.\n",
+ "Now that the model has been defined and initialized, we can solve the model.\n",
"\n",
"
\n",
"
Inline Exercise:\n",
@@ -817,7 +817,7 @@
"source": [
"
\n",
"Inline Exercise:\n",
- "Repeate the exercise above, but create a figure showing the heat duty vs. the mole fraction of Benzene in the vapor outlet. Remove any unnecessary printing to create cleaner results.\n",
+ "Repeat the exercise above, but create a figure showing the heat duty vs. the mole fraction of Benzene in the vapor outlet. Remove any unnecessary printing to create cleaner results.\n",
"
"
]
},
diff --git a/idaes_examples/notebooks/docs/tut/core/flash_unit_doc.ipynb b/idaes_examples/notebooks/docs/tut/core/flash_unit_doc.ipynb
index 9022c9a2..9432ccbe 100644
--- a/idaes_examples/notebooks/docs/tut/core/flash_unit_doc.ipynb
+++ b/idaes_examples/notebooks/docs/tut/core/flash_unit_doc.ipynb
@@ -552,7 +552,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "Now that the model has been defined and intialized, we can solve the model.\n",
+ "Now that the model has been defined and initialized, we can solve the model.\n",
"\n",
"
\n",
"
Inline Exercise:\n",
@@ -1275,7 +1275,7 @@
"source": [
"
\n",
"Inline Exercise:\n",
- "Repeate the exercise above, but create a figure showing the heat duty vs. the mole fraction of Benzene in the vapor outlet. Remove any unnecessary printing to create cleaner results.\n",
+ "Repeat the exercise above, but create a figure showing the heat duty vs. the mole fraction of Benzene in the vapor outlet. Remove any unnecessary printing to create cleaner results.\n",
"
"
]
},
@@ -1909,4 +1909,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/tut/core/flash_unit_exercise.ipynb b/idaes_examples/notebooks/docs/tut/core/flash_unit_exercise.ipynb
index fc8c25ec..19e3b691 100644
--- a/idaes_examples/notebooks/docs/tut/core/flash_unit_exercise.ipynb
+++ b/idaes_examples/notebooks/docs/tut/core/flash_unit_exercise.ipynb
@@ -391,7 +391,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "Now that the model has been defined and intialized, we can solve the model.\n",
+ "Now that the model has been defined and initialized, we can solve the model.\n",
"\n",
"
\n",
"
Inline Exercise:\n",
@@ -572,7 +572,7 @@
"source": [
"
\n",
"Inline Exercise:\n",
- "Repeate the exercise above, but create a figure showing the heat duty vs. the mole fraction of Benzene in the vapor outlet. Remove any unnecessary printing to create cleaner results.\n",
+ "Repeat the exercise above, but create a figure showing the heat duty vs. the mole fraction of Benzene in the vapor outlet. Remove any unnecessary printing to create cleaner results.\n",
"
"
]
},
@@ -654,4 +654,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/tut/core/flash_unit_solution.ipynb b/idaes_examples/notebooks/docs/tut/core/flash_unit_solution.ipynb
index 866c48fa..6b4b3752 100644
--- a/idaes_examples/notebooks/docs/tut/core/flash_unit_solution.ipynb
+++ b/idaes_examples/notebooks/docs/tut/core/flash_unit_solution.ipynb
@@ -486,7 +486,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "Now that the model has been defined and intialized, we can solve the model.\n",
+ "Now that the model has been defined and initialized, we can solve the model.\n",
"\n",
"
\n",
"
Inline Exercise:\n",
@@ -739,7 +739,7 @@
"source": [
"
\n",
"Inline Exercise:\n",
- "Repeate the exercise above, but create a figure showing the heat duty vs. the mole fraction of Benzene in the vapor outlet. Remove any unnecessary printing to create cleaner results.\n",
+ "Repeat the exercise above, but create a figure showing the heat duty vs. the mole fraction of Benzene in the vapor outlet. Remove any unnecessary printing to create cleaner results.\n",
"
"
]
},
@@ -893,4 +893,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/tut/core/flash_unit_test.ipynb b/idaes_examples/notebooks/docs/tut/core/flash_unit_test.ipynb
index 3a2bff71..562af431 100644
--- a/idaes_examples/notebooks/docs/tut/core/flash_unit_test.ipynb
+++ b/idaes_examples/notebooks/docs/tut/core/flash_unit_test.ipynb
@@ -430,7 +430,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "Now that the model has been defined and intialized, we can solve the model.\n",
+ "Now that the model has been defined and initialized, we can solve the model.\n",
"\n",
"
\n",
"
Inline Exercise:\n",
@@ -664,7 +664,7 @@
"source": [
"
\n",
"Inline Exercise:\n",
- "Repeate the exercise above, but create a figure showing the heat duty vs. the mole fraction of Benzene in the vapor outlet. Remove any unnecessary printing to create cleaner results.\n",
+ "Repeat the exercise above, but create a figure showing the heat duty vs. the mole fraction of Benzene in the vapor outlet. Remove any unnecessary printing to create cleaner results.\n",
"
"
]
},
@@ -814,4 +814,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/tut/core/flash_unit_usr.ipynb b/idaes_examples/notebooks/docs/tut/core/flash_unit_usr.ipynb
index 866c48fa..6b4b3752 100644
--- a/idaes_examples/notebooks/docs/tut/core/flash_unit_usr.ipynb
+++ b/idaes_examples/notebooks/docs/tut/core/flash_unit_usr.ipynb
@@ -486,7 +486,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "Now that the model has been defined and intialized, we can solve the model.\n",
+ "Now that the model has been defined and initialized, we can solve the model.\n",
"\n",
"
\n",
"
Inline Exercise:\n",
@@ -739,7 +739,7 @@
"source": [
"
\n",
"Inline Exercise:\n",
- "Repeate the exercise above, but create a figure showing the heat duty vs. the mole fraction of Benzene in the vapor outlet. Remove any unnecessary printing to create cleaner results.\n",
+ "Repeat the exercise above, but create a figure showing the heat duty vs. the mole fraction of Benzene in the vapor outlet. Remove any unnecessary printing to create cleaner results.\n",
"
"
]
},
@@ -893,4 +893,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/tut/core/hda_flowsheet.ipynb b/idaes_examples/notebooks/docs/tut/core/hda_flowsheet.ipynb
index a9d3525b..3a4ad898 100644
--- a/idaes_examples/notebooks/docs/tut/core/hda_flowsheet.ipynb
+++ b/idaes_examples/notebooks/docs/tut/core/hda_flowsheet.ipynb
@@ -74,8 +74,7 @@
"The state variables chosen for the property package are **flows of component by phase, temperature and pressure**. The components considered are: **toluene, hydrogen, benzene and methane**. Therefore, every stream has 8 flow variables, 1 temperature and 1 pressure variable. \n",
"\n",
"\n",
- "\n",
- ""
+ "\n"
]
},
{
@@ -419,7 +418,7 @@
"source": [
"## Connecting Unit Models using Arcs\n",
"\n",
- "We have now added all the unit models we need to the flowsheet. However, we have not yet specifed how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the mixer(M101) to the inlet of the heater(H101). "
+ "We have now added all the unit models we need to the flowsheet. However, we have not yet specified how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the mixer(M101) to the inlet of the heater(H101). "
]
},
{
@@ -1176,7 +1175,7 @@
"source": [
"
\n",
"Inline Exercise:\n",
- "You can querry additional variables here if you like. \n",
+ "You can query additional variables here if you like. \n",
"\n",
"Use Shift+Enter to run the cell once you have typed in your code. \n",
"
\n"
diff --git a/idaes_examples/notebooks/docs/tut/core/hda_flowsheet_doc.ipynb b/idaes_examples/notebooks/docs/tut/core/hda_flowsheet_doc.ipynb
index 3ac7ea93..44fe440f 100644
--- a/idaes_examples/notebooks/docs/tut/core/hda_flowsheet_doc.ipynb
+++ b/idaes_examples/notebooks/docs/tut/core/hda_flowsheet_doc.ipynb
@@ -392,7 +392,7 @@
"source": [
"## Connecting Unit Models using Arcs\n",
"\n",
- "We have now added all the unit models we need to the flowsheet. However, we have not yet specifed how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the mixer(M101) to the inlet of the heater(H101). "
+ "We have now added all the unit models we need to the flowsheet. However, we have not yet specified how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the mixer(M101) to the inlet of the heater(H101). "
]
},
{
@@ -1688,7 +1688,7 @@
"source": [
"
\n",
"Inline Exercise:\n",
- "You can querry additional variables here if you like. \n",
+ "You can query additional variables here if you like. \n",
"\n",
"Use Shift+Enter to run the cell once you have typed in your code. \n",
"
\n"
@@ -2209,4 +2209,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/tut/core/hda_flowsheet_exercise.ipynb b/idaes_examples/notebooks/docs/tut/core/hda_flowsheet_exercise.ipynb
index f28e8d79..cd42cc58 100644
--- a/idaes_examples/notebooks/docs/tut/core/hda_flowsheet_exercise.ipynb
+++ b/idaes_examples/notebooks/docs/tut/core/hda_flowsheet_exercise.ipynb
@@ -56,7 +56,7 @@
"example, toluene will be reacted with hydrogen gas at high temperatures\n",
" to form benzene via the following reaction:\n",
"\n",
- "**C
6H
5CH
3 + H
2 \u2192 C
6H
6 + CH
4**\n",
+ "**C
6H
5CH
3 + H
2 → C
6H
6 + CH
4**\n",
"\n",
"\n",
"This reaction is often accompanied by an equilibrium side reaction\n",
@@ -74,8 +74,7 @@
"The state variables chosen for the property package are **flows of component by phase, temperature and pressure**. The components considered are: **toluene, hydrogen, benzene and methane**. Therefore, every stream has 8 flow variables, 1 temperature and 1 pressure variable. \n",
"\n",
"\n",
- "\n",
- ""
+ "\n"
]
},
{
@@ -385,7 +384,7 @@
"source": [
"## Connecting Unit Models using Arcs\n",
"\n",
- "We have now added all the unit models we need to the flowsheet. However, we have not yet specifed how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the mixer(M101) to the inlet of the heater(H101). "
+ "We have now added all the unit models we need to the flowsheet. However, we have not yet specified how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the mixer(M101) to the inlet of the heater(H101). "
]
},
{
@@ -1007,7 +1006,7 @@
"source": [
"
\n",
"Inline Exercise:\n",
- "You can querry additional variables here if you like. \n",
+ "You can query additional variables here if you like. \n",
"\n",
"Use Shift+Enter to run the cell once you have typed in your code. \n",
"
\n"
@@ -1335,4 +1334,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/tut/core/hda_flowsheet_solution.ipynb b/idaes_examples/notebooks/docs/tut/core/hda_flowsheet_solution.ipynb
index f54e0f4d..923daf60 100644
--- a/idaes_examples/notebooks/docs/tut/core/hda_flowsheet_solution.ipynb
+++ b/idaes_examples/notebooks/docs/tut/core/hda_flowsheet_solution.ipynb
@@ -56,7 +56,7 @@
"example, toluene will be reacted with hydrogen gas at high temperatures\n",
" to form benzene via the following reaction:\n",
"\n",
- "**C
6H
5CH
3 + H
2 \u2192 C
6H
6 + CH
4**\n",
+ "**C
6H
5CH
3 + H
2 → C
6H
6 + CH
4**\n",
"\n",
"\n",
"This reaction is often accompanied by an equilibrium side reaction\n",
@@ -74,8 +74,7 @@
"The state variables chosen for the property package are **flows of component by phase, temperature and pressure**. The components considered are: **toluene, hydrogen, benzene and methane**. Therefore, every stream has 8 flow variables, 1 temperature and 1 pressure variable. \n",
"\n",
"\n",
- "\n",
- ""
+ "\n"
]
},
{
@@ -419,7 +418,7 @@
"source": [
"## Connecting Unit Models using Arcs\n",
"\n",
- "We have now added all the unit models we need to the flowsheet. However, we have not yet specifed how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the mixer(M101) to the inlet of the heater(H101). "
+ "We have now added all the unit models we need to the flowsheet. However, we have not yet specified how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the mixer(M101) to the inlet of the heater(H101). "
]
},
{
@@ -1101,7 +1100,7 @@
"source": [
"
\n",
"Inline Exercise:\n",
- "You can querry additional variables here if you like. \n",
+ "You can query additional variables here if you like. \n",
"\n",
"Use Shift+Enter to run the cell once you have typed in your code. \n",
"
\n"
@@ -1474,4 +1473,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/tut/core/hda_flowsheet_test.ipynb b/idaes_examples/notebooks/docs/tut/core/hda_flowsheet_test.ipynb
index 8aa3ab41..7098c670 100644
--- a/idaes_examples/notebooks/docs/tut/core/hda_flowsheet_test.ipynb
+++ b/idaes_examples/notebooks/docs/tut/core/hda_flowsheet_test.ipynb
@@ -56,7 +56,7 @@
"example, toluene will be reacted with hydrogen gas at high temperatures\n",
" to form benzene via the following reaction:\n",
"\n",
- "**C
6H
5CH
3 + H
2 \u2192 C
6H
6 + CH
4**\n",
+ "**C
6H
5CH
3 + H
2 → C
6H
6 + CH
4**\n",
"\n",
"\n",
"This reaction is often accompanied by an equilibrium side reaction\n",
@@ -74,8 +74,7 @@
"The state variables chosen for the property package are **flows of component by phase, temperature and pressure**. The components considered are: **toluene, hydrogen, benzene and methane**. Therefore, every stream has 8 flow variables, 1 temperature and 1 pressure variable. \n",
"\n",
"\n",
- "\n",
- ""
+ "\n"
]
},
{
@@ -393,7 +392,7 @@
"source": [
"## Connecting Unit Models using Arcs\n",
"\n",
- "We have now added all the unit models we need to the flowsheet. However, we have not yet specifed how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the mixer(M101) to the inlet of the heater(H101). "
+ "We have now added all the unit models we need to the flowsheet. However, we have not yet specified how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the mixer(M101) to the inlet of the heater(H101). "
]
},
{
@@ -1095,7 +1094,7 @@
"source": [
"
\n",
"Inline Exercise:\n",
- "You can querry additional variables here if you like. \n",
+ "You can query additional variables here if you like. \n",
"\n",
"Use Shift+Enter to run the cell once you have typed in your code. \n",
"
\n"
@@ -1489,4 +1488,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/tut/core/hda_flowsheet_usr.ipynb b/idaes_examples/notebooks/docs/tut/core/hda_flowsheet_usr.ipynb
index f54e0f4d..923daf60 100644
--- a/idaes_examples/notebooks/docs/tut/core/hda_flowsheet_usr.ipynb
+++ b/idaes_examples/notebooks/docs/tut/core/hda_flowsheet_usr.ipynb
@@ -56,7 +56,7 @@
"example, toluene will be reacted with hydrogen gas at high temperatures\n",
" to form benzene via the following reaction:\n",
"\n",
- "**C
6H
5CH
3 + H
2 \u2192 C
6H
6 + CH
4**\n",
+ "**C
6H
5CH
3 + H
2 → C
6H
6 + CH
4**\n",
"\n",
"\n",
"This reaction is often accompanied by an equilibrium side reaction\n",
@@ -74,8 +74,7 @@
"The state variables chosen for the property package are **flows of component by phase, temperature and pressure**. The components considered are: **toluene, hydrogen, benzene and methane**. Therefore, every stream has 8 flow variables, 1 temperature and 1 pressure variable. \n",
"\n",
"\n",
- "\n",
- ""
+ "\n"
]
},
{
@@ -419,7 +418,7 @@
"source": [
"## Connecting Unit Models using Arcs\n",
"\n",
- "We have now added all the unit models we need to the flowsheet. However, we have not yet specifed how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the mixer(M101) to the inlet of the heater(H101). "
+ "We have now added all the unit models we need to the flowsheet. However, we have not yet specified how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the mixer(M101) to the inlet of the heater(H101). "
]
},
{
@@ -1101,7 +1100,7 @@
"source": [
"
\n",
"Inline Exercise:\n",
- "You can querry additional variables here if you like. \n",
+ "You can query additional variables here if you like. \n",
"\n",
"Use Shift+Enter to run the cell once you have typed in your code. \n",
"
\n"
@@ -1474,4 +1473,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/custom_unit_models/custom_compressor.ipynb b/idaes_examples/notebooks/docs/unit_models/custom_unit_models/custom_compressor.ipynb
index 27c351a3..47f203dd 100644
--- a/idaes_examples/notebooks/docs/unit_models/custom_unit_models/custom_compressor.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/custom_unit_models/custom_compressor.ipynb
@@ -222,7 +222,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "Finally, we can define the ideal-gas isentropic compressor. To do so, we create a class called ``IdealGasIsentropicCompressorData`` and use the ``declare_process_block_class`` decorator. For now, just consider the decorator to be boiler-plate. We then need to define the config block and write the ``build`` method. The ``build`` method should alwasy call ``super``. Next, we simply call the functions we wrote to build the control volume, energy balance, and electricity requirement performance equation. Finally, we need to call ``self.add_inlet_port()`` and ``self.add_outlet_port()``. These methods need to be called in order to create the ports which are used for connecting the unit to other units."
+ "Finally, we can define the ideal-gas isentropic compressor. To do so, we create a class called ``IdealGasIsentropicCompressorData`` and use the ``declare_process_block_class`` decorator. For now, just consider the decorator to be boiler-plate. We then need to define the config block and write the ``build`` method. The ``build`` method should always call ``super``. Next, we simply call the functions we wrote to build the control volume, energy balance, and electricity requirement performance equation. Finally, we need to call ``self.add_inlet_port()`` and ``self.add_outlet_port()``. These methods need to be called in order to create the ports which are used for connecting the unit to other units."
]
},
{
diff --git a/idaes_examples/notebooks/docs/unit_models/custom_unit_models/custom_compressor_doc.ipynb b/idaes_examples/notebooks/docs/unit_models/custom_unit_models/custom_compressor_doc.ipynb
index 23657231..88f645ec 100644
--- a/idaes_examples/notebooks/docs/unit_models/custom_unit_models/custom_compressor_doc.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/custom_unit_models/custom_compressor_doc.ipynb
@@ -222,7 +222,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "Finally, we can define the ideal-gas isentropic compressor. To do so, we create a class called ``IdealGasIsentropicCompressorData`` and use the ``declare_process_block_class`` decorator. For now, just consider the decorator to be boiler-plate. We then need to define the config block and write the ``build`` method. The ``build`` method should alwasy call ``super``. Next, we simply call the functions we wrote to build the control volume, energy balance, and electricity requirement performance equation. Finally, we need to call ``self.add_inlet_port()`` and ``self.add_outlet_port()``. These methods need to be called in order to create the ports which are used for connecting the unit to other units."
+ "Finally, we can define the ideal-gas isentropic compressor. To do so, we create a class called ``IdealGasIsentropicCompressorData`` and use the ``declare_process_block_class`` decorator. For now, just consider the decorator to be boiler-plate. We then need to define the config block and write the ``build`` method. The ``build`` method should always call ``super``. Next, we simply call the functions we wrote to build the control volume, energy balance, and electricity requirement performance equation. Finally, we need to call ``self.add_inlet_port()`` and ``self.add_outlet_port()``. These methods need to be called in order to create the ports which are used for connecting the unit to other units."
]
},
{
@@ -396,4 +396,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/custom_unit_models/custom_compressor_test.ipynb b/idaes_examples/notebooks/docs/unit_models/custom_unit_models/custom_compressor_test.ipynb
index 2998d8b9..2aa3d42f 100644
--- a/idaes_examples/notebooks/docs/unit_models/custom_unit_models/custom_compressor_test.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/custom_unit_models/custom_compressor_test.ipynb
@@ -222,7 +222,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "Finally, we can define the ideal-gas isentropic compressor. To do so, we create a class called ``IdealGasIsentropicCompressorData`` and use the ``declare_process_block_class`` decorator. For now, just consider the decorator to be boiler-plate. We then need to define the config block and write the ``build`` method. The ``build`` method should alwasy call ``super``. Next, we simply call the functions we wrote to build the control volume, energy balance, and electricity requirement performance equation. Finally, we need to call ``self.add_inlet_port()`` and ``self.add_outlet_port()``. These methods need to be called in order to create the ports which are used for connecting the unit to other units."
+ "Finally, we can define the ideal-gas isentropic compressor. To do so, we create a class called ``IdealGasIsentropicCompressorData`` and use the ``declare_process_block_class`` decorator. For now, just consider the decorator to be boiler-plate. We then need to define the config block and write the ``build`` method. The ``build`` method should always call ``super``. Next, we simply call the functions we wrote to build the control volume, energy balance, and electricity requirement performance equation. Finally, we need to call ``self.add_inlet_port()`` and ``self.add_outlet_port()``. These methods need to be called in order to create the ports which are used for connecting the unit to other units."
]
},
{
@@ -344,4 +344,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/custom_unit_models/custom_compressor_usr.ipynb b/idaes_examples/notebooks/docs/unit_models/custom_unit_models/custom_compressor_usr.ipynb
index a5e63ef1..7441542a 100644
--- a/idaes_examples/notebooks/docs/unit_models/custom_unit_models/custom_compressor_usr.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/custom_unit_models/custom_compressor_usr.ipynb
@@ -222,7 +222,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "Finally, we can define the ideal-gas isentropic compressor. To do so, we create a class called ``IdealGasIsentropicCompressorData`` and use the ``declare_process_block_class`` decorator. For now, just consider the decorator to be boiler-plate. We then need to define the config block and write the ``build`` method. The ``build`` method should alwasy call ``super``. Next, we simply call the functions we wrote to build the control volume, energy balance, and electricity requirement performance equation. Finally, we need to call ``self.add_inlet_port()`` and ``self.add_outlet_port()``. These methods need to be called in order to create the ports which are used for connecting the unit to other units."
+ "Finally, we can define the ideal-gas isentropic compressor. To do so, we create a class called ``IdealGasIsentropicCompressorData`` and use the ``declare_process_block_class`` decorator. For now, just consider the decorator to be boiler-plate. We then need to define the config block and write the ``build`` method. The ``build`` method should always call ``super``. Next, we simply call the functions we wrote to build the control volume, energy balance, and electricity requirement performance equation. Finally, we need to call ``self.add_inlet_port()`` and ``self.add_outlet_port()``. These methods need to be called in order to create the ports which are used for connecting the unit to other units."
]
},
{
@@ -312,4 +312,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/operations/compressor.ipynb b/idaes_examples/notebooks/docs/unit_models/operations/compressor.ipynb
index 1573f978..f4e07086 100644
--- a/idaes_examples/notebooks/docs/unit_models/operations/compressor.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/operations/compressor.ipynb
@@ -41,7 +41,7 @@
"## Learning Outcomes\n",
"\n",
"- Demonstrate use of the compressor unit model in IDAES\n",
- "- Demonstarte use of the Span Wagner EOS for supercritical CO2 cycles\n",
+ "- Demonstrate use of the Span Wagner EOS for supercritical CO2 cycles\n",
"- Demonstrate different simulation options available for the compressor unit model\n",
"\n",
"In this tutorial, we will simulate the main compressor for an indirect supercritical CO2 cycle using the Span-Wagner EOS as the property package. The input specifications for this tutorial are from the NETL report on indirect SCO2 cycles available [here](https://www.osti.gov/biblio/1490272). In this example, we will be compressing supercritical CO2 from 9.1 MPa to 34.5 MPa. \n",
@@ -150,7 +150,7 @@
"# DOF = Number of Model Variables - Number of Model Constraints\n",
"from idaes.core.util.model_statistics import degrees_of_freedom\n",
"\n",
- "# Call the degrees_of_freedom function, get intitial DOF\n",
+ "# Call the degrees_of_freedom function, get initial DOF\n",
"DOF_initial = degrees_of_freedom(m)\n",
"print(\"The initial DOF is {0}\".format(DOF_initial))"
]
@@ -349,7 +349,7 @@
" thermodynamic_assumption=ThermodynamicAssumption.isentropic,\n",
")\n",
"\n",
- "# Call the degrees_of_freedom function, get intitial DOF\n",
+ "# Call the degrees_of_freedom function, get initial DOF\n",
"DOF_initial = degrees_of_freedom(m.fs.compr_case_2)\n",
"print(\"The initial DOF is {0}\".format(DOF_initial))"
]
diff --git a/idaes_examples/notebooks/docs/unit_models/operations/compressor_doc.ipynb b/idaes_examples/notebooks/docs/unit_models/operations/compressor_doc.ipynb
index 451aa3e8..d3f073fb 100644
--- a/idaes_examples/notebooks/docs/unit_models/operations/compressor_doc.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/operations/compressor_doc.ipynb
@@ -41,7 +41,7 @@
"## Learning Outcomes\n",
"\n",
"- Demonstrate use of the compressor unit model in IDAES\n",
- "- Demonstarte use of the Span Wagner EOS for supercritical CO2 cycles\n",
+ "- Demonstrate use of the Span Wagner EOS for supercritical CO2 cycles\n",
"- Demonstrate different simulation options available for the compressor unit model\n",
"\n",
"In this tutorial, we will simulate the main compressor for an indirect supercritical CO2 cycle using the Span-Wagner EOS as the property package. The input specifications for this tutorial are from the NETL report on indirect SCO2 cycles available [here](https://www.osti.gov/biblio/1490272). In this example, we will be compressing supercritical CO2 from 9.1 MPa to 34.5 MPa. \n",
@@ -158,7 +158,7 @@
"# DOF = Number of Model Variables - Number of Model Constraints\n",
"from idaes.core.util.model_statistics import degrees_of_freedom\n",
"\n",
- "# Call the degrees_of_freedom function, get intitial DOF\n",
+ "# Call the degrees_of_freedom function, get initial DOF\n",
"DOF_initial = degrees_of_freedom(m)\n",
"print(\"The initial DOF is {0}\".format(DOF_initial))"
]
@@ -445,7 +445,7 @@
" thermodynamic_assumption=ThermodynamicAssumption.isentropic,\n",
")\n",
"\n",
- "# Call the degrees_of_freedom function, get intitial DOF\n",
+ "# Call the degrees_of_freedom function, get initial DOF\n",
"DOF_initial = degrees_of_freedom(m.fs.compr_case_2)\n",
"print(\"The initial DOF is {0}\".format(DOF_initial))"
]
@@ -710,4 +710,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/operations/compressor_test.ipynb b/idaes_examples/notebooks/docs/unit_models/operations/compressor_test.ipynb
index 9f081d50..7d354e12 100644
--- a/idaes_examples/notebooks/docs/unit_models/operations/compressor_test.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/operations/compressor_test.ipynb
@@ -41,7 +41,7 @@
"## Learning Outcomes\n",
"\n",
"- Demonstrate use of the compressor unit model in IDAES\n",
- "- Demonstarte use of the Span Wagner EOS for supercritical CO2 cycles\n",
+ "- Demonstrate use of the Span Wagner EOS for supercritical CO2 cycles\n",
"- Demonstrate different simulation options available for the compressor unit model\n",
"\n",
"In this tutorial, we will simulate the main compressor for an indirect supercritical CO2 cycle using the Span-Wagner EOS as the property package. The input specifications for this tutorial are from the NETL report on indirect SCO2 cycles available [here](https://www.osti.gov/biblio/1490272). In this example, we will be compressing supercritical CO2 from 9.1 MPa to 34.5 MPa. \n",
@@ -150,7 +150,7 @@
"# DOF = Number of Model Variables - Number of Model Constraints\n",
"from idaes.core.util.model_statistics import degrees_of_freedom\n",
"\n",
- "# Call the degrees_of_freedom function, get intitial DOF\n",
+ "# Call the degrees_of_freedom function, get initial DOF\n",
"DOF_initial = degrees_of_freedom(m)\n",
"print(\"The initial DOF is {0}\".format(DOF_initial))"
]
@@ -349,7 +349,7 @@
" thermodynamic_assumption=ThermodynamicAssumption.isentropic,\n",
")\n",
"\n",
- "# Call the degrees_of_freedom function, get intitial DOF\n",
+ "# Call the degrees_of_freedom function, get initial DOF\n",
"DOF_initial = degrees_of_freedom(m.fs.compr_case_2)\n",
"print(\"The initial DOF is {0}\".format(DOF_initial))"
]
@@ -557,4 +557,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/operations/compressor_usr.ipynb b/idaes_examples/notebooks/docs/unit_models/operations/compressor_usr.ipynb
index 993c7a93..097aedb3 100644
--- a/idaes_examples/notebooks/docs/unit_models/operations/compressor_usr.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/operations/compressor_usr.ipynb
@@ -41,7 +41,7 @@
"## Learning Outcomes\n",
"\n",
"- Demonstrate use of the compressor unit model in IDAES\n",
- "- Demonstarte use of the Span Wagner EOS for supercritical CO2 cycles\n",
+ "- Demonstrate use of the Span Wagner EOS for supercritical CO2 cycles\n",
"- Demonstrate different simulation options available for the compressor unit model\n",
"\n",
"In this tutorial, we will simulate the main compressor for an indirect supercritical CO2 cycle using the Span-Wagner EOS as the property package. The input specifications for this tutorial are from the NETL report on indirect SCO2 cycles available [here](https://www.osti.gov/biblio/1490272). In this example, we will be compressing supercritical CO2 from 9.1 MPa to 34.5 MPa. \n",
@@ -150,7 +150,7 @@
"# DOF = Number of Model Variables - Number of Model Constraints\n",
"from idaes.core.util.model_statistics import degrees_of_freedom\n",
"\n",
- "# Call the degrees_of_freedom function, get intitial DOF\n",
+ "# Call the degrees_of_freedom function, get initial DOF\n",
"DOF_initial = degrees_of_freedom(m)\n",
"print(\"The initial DOF is {0}\".format(DOF_initial))"
]
@@ -292,7 +292,7 @@
" thermodynamic_assumption=ThermodynamicAssumption.isentropic,\n",
")\n",
"\n",
- "# Call the degrees_of_freedom function, get intitial DOF\n",
+ "# Call the degrees_of_freedom function, get initial DOF\n",
"DOF_initial = degrees_of_freedom(m.fs.compr_case_2)\n",
"print(\"The initial DOF is {0}\".format(DOF_initial))"
]
@@ -431,4 +431,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/operations/heat_exchanger_0d.ipynb b/idaes_examples/notebooks/docs/unit_models/operations/heat_exchanger_0d.ipynb
index 35938194..d7f22f19 100644
--- a/idaes_examples/notebooks/docs/unit_models/operations/heat_exchanger_0d.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/operations/heat_exchanger_0d.ipynb
@@ -144,7 +144,7 @@
" tube={\"property_package\": m.fs.properties_tube},\n",
")\n",
"\n",
- "# Call the degrees_of_freedom function, get intitial DOF\n",
+ "# Call the degrees_of_freedom function, get initial DOF\n",
"DOF_initial = degrees_of_freedom(m)\n",
"print(\"The initial DOF is {0}\".format(DOF_initial))"
]
diff --git a/idaes_examples/notebooks/docs/unit_models/operations/heat_exchanger_0d_doc.ipynb b/idaes_examples/notebooks/docs/unit_models/operations/heat_exchanger_0d_doc.ipynb
index aec04e6f..bd16e69e 100644
--- a/idaes_examples/notebooks/docs/unit_models/operations/heat_exchanger_0d_doc.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/operations/heat_exchanger_0d_doc.ipynb
@@ -152,7 +152,7 @@
" tube={\"property_package\": m.fs.properties_tube},\n",
")\n",
"\n",
- "# Call the degrees_of_freedom function, get intitial DOF\n",
+ "# Call the degrees_of_freedom function, get initial DOF\n",
"DOF_initial = degrees_of_freedom(m)\n",
"print(\"The initial DOF is {0}\".format(DOF_initial))"
]
@@ -534,4 +534,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/operations/heat_exchanger_0d_test.ipynb b/idaes_examples/notebooks/docs/unit_models/operations/heat_exchanger_0d_test.ipynb
index 4c392c89..573ea6df 100644
--- a/idaes_examples/notebooks/docs/unit_models/operations/heat_exchanger_0d_test.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/operations/heat_exchanger_0d_test.ipynb
@@ -144,7 +144,7 @@
" tube={\"property_package\": m.fs.properties_tube},\n",
")\n",
"\n",
- "# Call the degrees_of_freedom function, get intitial DOF\n",
+ "# Call the degrees_of_freedom function, get initial DOF\n",
"DOF_initial = degrees_of_freedom(m)\n",
"print(\"The initial DOF is {0}\".format(DOF_initial))"
]
@@ -357,4 +357,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/operations/heat_exchanger_0d_usr.ipynb b/idaes_examples/notebooks/docs/unit_models/operations/heat_exchanger_0d_usr.ipynb
index 970a6420..03106f87 100644
--- a/idaes_examples/notebooks/docs/unit_models/operations/heat_exchanger_0d_usr.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/operations/heat_exchanger_0d_usr.ipynb
@@ -144,7 +144,7 @@
" tube={\"property_package\": m.fs.properties_tube},\n",
")\n",
"\n",
- "# Call the degrees_of_freedom function, get intitial DOF\n",
+ "# Call the degrees_of_freedom function, get initial DOF\n",
"DOF_initial = degrees_of_freedom(m)\n",
"print(\"The initial DOF is {0}\".format(DOF_initial))"
]
@@ -286,4 +286,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/operations/heater.ipynb b/idaes_examples/notebooks/docs/unit_models/operations/heater.ipynb
index 8338e1d7..5774adcb 100644
--- a/idaes_examples/notebooks/docs/unit_models/operations/heater.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/operations/heater.ipynb
@@ -116,7 +116,7 @@
"from idaes.core.util.model_statistics import degrees_of_freedom\n",
"\n",
"\n",
- "# Call the degrees_of_freedom function, get intitial DOF\n",
+ "# Call the degrees_of_freedom function, get initial DOF\n",
"DOF_initial = degrees_of_freedom(m)\n",
"print(\"The initial DOF is {0}\".format(DOF_initial))"
]
diff --git a/idaes_examples/notebooks/docs/unit_models/operations/heater_doc.ipynb b/idaes_examples/notebooks/docs/unit_models/operations/heater_doc.ipynb
index 239de3fd..65fc12f9 100644
--- a/idaes_examples/notebooks/docs/unit_models/operations/heater_doc.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/operations/heater_doc.ipynb
@@ -124,7 +124,7 @@
"from idaes.core.util.model_statistics import degrees_of_freedom\n",
"\n",
"\n",
- "# Call the degrees_of_freedom function, get intitial DOF\n",
+ "# Call the degrees_of_freedom function, get initial DOF\n",
"DOF_initial = degrees_of_freedom(m)\n",
"print(\"The initial DOF is {0}\".format(DOF_initial))"
]
@@ -726,4 +726,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/operations/heater_test.ipynb b/idaes_examples/notebooks/docs/unit_models/operations/heater_test.ipynb
index 28f8bfa6..c845805c 100644
--- a/idaes_examples/notebooks/docs/unit_models/operations/heater_test.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/operations/heater_test.ipynb
@@ -116,7 +116,7 @@
"from idaes.core.util.model_statistics import degrees_of_freedom\n",
"\n",
"\n",
- "# Call the degrees_of_freedom function, get intitial DOF\n",
+ "# Call the degrees_of_freedom function, get initial DOF\n",
"DOF_initial = degrees_of_freedom(m)\n",
"print(\"The initial DOF is {0}\".format(DOF_initial))"
]
@@ -472,4 +472,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/operations/heater_usr.ipynb b/idaes_examples/notebooks/docs/unit_models/operations/heater_usr.ipynb
index c4969473..ea1b4363 100644
--- a/idaes_examples/notebooks/docs/unit_models/operations/heater_usr.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/operations/heater_usr.ipynb
@@ -116,7 +116,7 @@
"from idaes.core.util.model_statistics import degrees_of_freedom\n",
"\n",
"\n",
- "# Call the degrees_of_freedom function, get intitial DOF\n",
+ "# Call the degrees_of_freedom function, get initial DOF\n",
"DOF_initial = degrees_of_freedom(m)\n",
"print(\"The initial DOF is {0}\".format(DOF_initial))"
]
@@ -366,4 +366,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/operations/pump.ipynb b/idaes_examples/notebooks/docs/unit_models/operations/pump.ipynb
index da4d0228..1fa67e77 100644
--- a/idaes_examples/notebooks/docs/unit_models/operations/pump.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/operations/pump.ipynb
@@ -149,7 +149,7 @@
"# DOF = Number of Model Variables - Number of Model Constraints\n",
"from idaes.core.util.model_statistics import degrees_of_freedom\n",
"\n",
- "# Call the degrees_of_freedom function, get intitial DOF\n",
+ "# Call the degrees_of_freedom function, get initial DOF\n",
"DOF_initial = degrees_of_freedom(m)\n",
"print(\"The initial DOF is {0}\".format(DOF_initial))"
]
@@ -343,7 +343,7 @@
"# Specify that the property package to be used with the pump is the one we created earlier.\n",
"m.fs.pump_case_2 = Pump(property_package=m.fs.properties)\n",
"\n",
- "# Call the degrees_of_freedom function, get intitial DOF\n",
+ "# Call the degrees_of_freedom function, get initial DOF\n",
"DOF_initial = degrees_of_freedom(m.fs.pump_case_2)\n",
"print(\"The initial DOF is {0}\".format(DOF_initial))"
]
diff --git a/idaes_examples/notebooks/docs/unit_models/operations/pump_doc.ipynb b/idaes_examples/notebooks/docs/unit_models/operations/pump_doc.ipynb
index 249fc935..a03e1227 100644
--- a/idaes_examples/notebooks/docs/unit_models/operations/pump_doc.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/operations/pump_doc.ipynb
@@ -157,7 +157,7 @@
"# DOF = Number of Model Variables - Number of Model Constraints\n",
"from idaes.core.util.model_statistics import degrees_of_freedom\n",
"\n",
- "# Call the degrees_of_freedom function, get intitial DOF\n",
+ "# Call the degrees_of_freedom function, get initial DOF\n",
"DOF_initial = degrees_of_freedom(m)\n",
"print(\"The initial DOF is {0}\".format(DOF_initial))"
]
@@ -434,7 +434,7 @@
"# Specify that the property package to be used with the pump is the one we created earlier.\n",
"m.fs.pump_case_2 = Pump(property_package=m.fs.properties)\n",
"\n",
- "# Call the degrees_of_freedom function, get intitial DOF\n",
+ "# Call the degrees_of_freedom function, get initial DOF\n",
"DOF_initial = degrees_of_freedom(m.fs.pump_case_2)\n",
"print(\"The initial DOF is {0}\".format(DOF_initial))"
]
@@ -691,4 +691,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/operations/pump_test.ipynb b/idaes_examples/notebooks/docs/unit_models/operations/pump_test.ipynb
index 54fadf60..f1ba0ff3 100644
--- a/idaes_examples/notebooks/docs/unit_models/operations/pump_test.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/operations/pump_test.ipynb
@@ -149,7 +149,7 @@
"# DOF = Number of Model Variables - Number of Model Constraints\n",
"from idaes.core.util.model_statistics import degrees_of_freedom\n",
"\n",
- "# Call the degrees_of_freedom function, get intitial DOF\n",
+ "# Call the degrees_of_freedom function, get initial DOF\n",
"DOF_initial = degrees_of_freedom(m)\n",
"print(\"The initial DOF is {0}\".format(DOF_initial))"
]
@@ -343,7 +343,7 @@
"# Specify that the property package to be used with the pump is the one we created earlier.\n",
"m.fs.pump_case_2 = Pump(property_package=m.fs.properties)\n",
"\n",
- "# Call the degrees_of_freedom function, get intitial DOF\n",
+ "# Call the degrees_of_freedom function, get initial DOF\n",
"DOF_initial = degrees_of_freedom(m.fs.pump_case_2)\n",
"print(\"The initial DOF is {0}\".format(DOF_initial))"
]
@@ -535,4 +535,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/operations/pump_usr.ipynb b/idaes_examples/notebooks/docs/unit_models/operations/pump_usr.ipynb
index 077bdb37..15e6db9a 100644
--- a/idaes_examples/notebooks/docs/unit_models/operations/pump_usr.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/operations/pump_usr.ipynb
@@ -149,7 +149,7 @@
"# DOF = Number of Model Variables - Number of Model Constraints\n",
"from idaes.core.util.model_statistics import degrees_of_freedom\n",
"\n",
- "# Call the degrees_of_freedom function, get intitial DOF\n",
+ "# Call the degrees_of_freedom function, get initial DOF\n",
"DOF_initial = degrees_of_freedom(m)\n",
"print(\"The initial DOF is {0}\".format(DOF_initial))"
]
@@ -283,7 +283,7 @@
"# Specify that the property package to be used with the pump is the one we created earlier.\n",
"m.fs.pump_case_2 = Pump(property_package=m.fs.properties)\n",
"\n",
- "# Call the degrees_of_freedom function, get intitial DOF\n",
+ "# Call the degrees_of_freedom function, get initial DOF\n",
"DOF_initial = degrees_of_freedom(m.fs.pump_case_2)\n",
"print(\"The initial DOF is {0}\".format(DOF_initial))"
]
@@ -417,4 +417,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/operations/skeleton_unit.ipynb b/idaes_examples/notebooks/docs/unit_models/operations/skeleton_unit.ipynb
index 042becc3..922f495f 100644
--- a/idaes_examples/notebooks/docs/unit_models/operations/skeleton_unit.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/operations/skeleton_unit.ipynb
@@ -47,7 +47,7 @@
"\n",
"In many cases, a specific application requires a unique unit operation that does not exist in the IDAES repository. Custom user models may source from external scripts, import surrogate equations or use first-principles calculations. However, IDAES flowsheets adhere to a standardized modeling hierarchy and simple Pyomo models do not always follow these conventions. Additionally, simple flowsheet submodels often require integration with other IDAES unit models which requires consistency between corresponding port variables, stream properties and physical unit sets, as well as proper usage of `ControlVolume` blocks.\n",
"\n",
- "The IDAES `SkeletonUnitModel` allows custom creation of user models blocks that do not require `ControlVolume` blocks, and enabling connection with standard IDAES unit models that do contain `ControlVolume` blocks. To motivate the usefulness and versatility of this tool, we will consider a simple pervaporation unit. The custom model does not require rigourous thermodynamic calculations contained in adjacent unit models, and using a Skeleton model allows definition of only required variables and constraints. The new block does require state variable connections for the inlet and outlet streams. We will demonstrate this scenario below to highlight the usage and benefits of the Skeleton model."
+ "The IDAES `SkeletonUnitModel` allows custom creation of user models blocks that do not require `ControlVolume` blocks, and enabling connection with standard IDAES unit models that do contain `ControlVolume` blocks. To motivate the usefulness and versatility of this tool, we will consider a simple pervaporation unit. The custom model does not require rigorous thermodynamic calculations contained in adjacent unit models, and using a Skeleton model allows definition of only required variables and constraints. The new block does require state variable connections for the inlet and outlet streams. We will demonstrate this scenario below to highlight the usage and benefits of the Skeleton model."
]
},
{
@@ -56,7 +56,7 @@
"source": [
"# 2. Example - Pervaporation\n",
"\n",
- "Pervaporation is a low-energy separation process, and is particularly advantageous over distillation for azeotropic solutions or aqueous mixtures of heavy alcohols. Ethylene glycol is more environmentally friendly than typical chloride- and bromide-based dessicants, and is a common choice for commericial recovery of water from flue gas via liquid spray columns. Due to ethylene glycol's high boiling point, diffusion-based water recovery is economically favorable compared to distillation-based processes. The following example and flux correlation are taken from the literature source below:\n",
+ "Pervaporation is a low-energy separation process, and is particularly advantageous over distillation for azeotropic solutions or aqueous mixtures of heavy alcohols. Ethylene glycol is more environmentally friendly than typical chloride- and bromide-based dessicants, and is a common choice for commercial recovery of water from flue gas via liquid spray columns. Due to ethylene glycol's high boiling point, diffusion-based water recovery is economically favorable compared to distillation-based processes. The following example and flux correlation are taken from the literature source below:\n",
"\n",
"Jennifer Runhong Du, Amit Chakma, X. Feng, Dehydration of ethylene glycol by pervaporation using poly(N,N-dimethylaminoethyl methacrylate)/polysulfone composite membranes, Separation and Purification Technology, Volume 64, Issue 1, 2008, Pages 63-70, ISSN 1383-5866, https://doi.org/10.1016/j.seppur.2008.08.004.\n",
"\n",
@@ -429,7 +429,7 @@
"metadata": {},
"source": [
"## 2.4 Custom Initialization\n",
- "In addition to allowing custom variable and constraint defintions, the Skeleton model enables implementation of a custom initialization scheme. Complex unit operations may present unique tractability issues, and users have precise control over piecewise unit model solving."
+ "In addition to allowing custom variable and constraint definitions, the Skeleton model enables implementation of a custom initialization scheme. Complex unit operations may present unique tractability issues, and users have precise control over piecewise unit model solving."
]
},
{
diff --git a/idaes_examples/notebooks/docs/unit_models/operations/skeleton_unit_doc.ipynb b/idaes_examples/notebooks/docs/unit_models/operations/skeleton_unit_doc.ipynb
index 8a31d626..0273e79d 100644
--- a/idaes_examples/notebooks/docs/unit_models/operations/skeleton_unit_doc.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/operations/skeleton_unit_doc.ipynb
@@ -47,7 +47,7 @@
"\n",
"In many cases, a specific application requires a unique unit operation that does not exist in the IDAES repository. Custom user models may source from external scripts, import surrogate equations or use first-principles calculations. However, IDAES flowsheets adhere to a standardized modeling hierarchy and simple Pyomo models do not always follow these conventions. Additionally, simple flowsheet submodels often require integration with other IDAES unit models which requires consistency between corresponding port variables, stream properties and physical unit sets, as well as proper usage of `ControlVolume` blocks.\n",
"\n",
- "The IDAES `SkeletonUnitModel` allows custom creation of user models blocks that do not require `ControlVolume` blocks, and enabling connection with standard IDAES unit models that do contain `ControlVolume` blocks. To motivate the usefulness and versatility of this tool, we will consider a simple pervaporation unit. The custom model does not require rigourous thermodynamic calculations contained in adjacent unit models, and using a Skeleton model allows definition of only required variables and constraints. The new block does require state variable connections for the inlet and outlet streams. We will demonstrate this scenario below to highlight the usage and benefits of the Skeleton model."
+ "The IDAES `SkeletonUnitModel` allows custom creation of user models blocks that do not require `ControlVolume` blocks, and enabling connection with standard IDAES unit models that do contain `ControlVolume` blocks. To motivate the usefulness and versatility of this tool, we will consider a simple pervaporation unit. The custom model does not require rigorous thermodynamic calculations contained in adjacent unit models, and using a Skeleton model allows definition of only required variables and constraints. The new block does require state variable connections for the inlet and outlet streams. We will demonstrate this scenario below to highlight the usage and benefits of the Skeleton model."
]
},
{
@@ -56,7 +56,7 @@
"source": [
"# 2. Example - Pervaporation\n",
"\n",
- "Pervaporation is a low-energy separation process, and is particularly advantageous over distillation for azeotropic solutions or aqueous mixtures of heavy alcohols. Ethylene glycol is more environmentally friendly than typical chloride- and bromide-based dessicants, and is a common choice for commericial recovery of water from flue gas via liquid spray columns. Due to ethylene glycol's high boiling point, diffusion-based water recovery is economically favorable compared to distillation-based processes. The following example and flux correlation are taken from the literature source below:\n",
+ "Pervaporation is a low-energy separation process, and is particularly advantageous over distillation for azeotropic solutions or aqueous mixtures of heavy alcohols. Ethylene glycol is more environmentally friendly than typical chloride- and bromide-based dessicants, and is a common choice for commercial recovery of water from flue gas via liquid spray columns. Due to ethylene glycol's high boiling point, diffusion-based water recovery is economically favorable compared to distillation-based processes. The following example and flux correlation are taken from the literature source below:\n",
"\n",
"Jennifer Runhong Du, Amit Chakma, X. Feng, Dehydration of ethylene glycol by pervaporation using poly(N,N-dimethylaminoethyl methacrylate)/polysulfone composite membranes, Separation and Purification Technology, Volume 64, Issue 1, 2008, Pages 63-70, ISSN 1383-5866, https://doi.org/10.1016/j.seppur.2008.08.004.\n",
"\n",
@@ -437,7 +437,7 @@
"metadata": {},
"source": [
"## 2.4 Custom Initialization\n",
- "In addition to allowing custom variable and constraint defintions, the Skeleton model enables implementation of a custom initialization scheme. Complex unit operations may present unique tractability issues, and users have precise control over piecewise unit model solving."
+ "In addition to allowing custom variable and constraint definitions, the Skeleton model enables implementation of a custom initialization scheme. Complex unit operations may present unique tractability issues, and users have precise control over piecewise unit model solving."
]
},
{
@@ -1205,4 +1205,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/operations/skeleton_unit_test.ipynb b/idaes_examples/notebooks/docs/unit_models/operations/skeleton_unit_test.ipynb
index 36155c95..9d9adfbe 100644
--- a/idaes_examples/notebooks/docs/unit_models/operations/skeleton_unit_test.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/operations/skeleton_unit_test.ipynb
@@ -47,7 +47,7 @@
"\n",
"In many cases, a specific application requires a unique unit operation that does not exist in the IDAES repository. Custom user models may source from external scripts, import surrogate equations or use first-principles calculations. However, IDAES flowsheets adhere to a standardized modeling hierarchy and simple Pyomo models do not always follow these conventions. Additionally, simple flowsheet submodels often require integration with other IDAES unit models which requires consistency between corresponding port variables, stream properties and physical unit sets, as well as proper usage of `ControlVolume` blocks.\n",
"\n",
- "The IDAES `SkeletonUnitModel` allows custom creation of user models blocks that do not require `ControlVolume` blocks, and enabling connection with standard IDAES unit models that do contain `ControlVolume` blocks. To motivate the usefulness and versatility of this tool, we will consider a simple pervaporation unit. The custom model does not require rigourous thermodynamic calculations contained in adjacent unit models, and using a Skeleton model allows definition of only required variables and constraints. The new block does require state variable connections for the inlet and outlet streams. We will demonstrate this scenario below to highlight the usage and benefits of the Skeleton model."
+ "The IDAES `SkeletonUnitModel` allows custom creation of user models blocks that do not require `ControlVolume` blocks, and enabling connection with standard IDAES unit models that do contain `ControlVolume` blocks. To motivate the usefulness and versatility of this tool, we will consider a simple pervaporation unit. The custom model does not require rigorous thermodynamic calculations contained in adjacent unit models, and using a Skeleton model allows definition of only required variables and constraints. The new block does require state variable connections for the inlet and outlet streams. We will demonstrate this scenario below to highlight the usage and benefits of the Skeleton model."
]
},
{
@@ -56,7 +56,7 @@
"source": [
"# 2. Example - Pervaporation\n",
"\n",
- "Pervaporation is a low-energy separation process, and is particularly advantageous over distillation for azeotropic solutions or aqueous mixtures of heavy alcohols. Ethylene glycol is more environmentally friendly than typical chloride- and bromide-based dessicants, and is a common choice for commericial recovery of water from flue gas via liquid spray columns. Due to ethylene glycol's high boiling point, diffusion-based water recovery is economically favorable compared to distillation-based processes. The following example and flux correlation are taken from the literature source below:\n",
+ "Pervaporation is a low-energy separation process, and is particularly advantageous over distillation for azeotropic solutions or aqueous mixtures of heavy alcohols. Ethylene glycol is more environmentally friendly than typical chloride- and bromide-based dessicants, and is a common choice for commercial recovery of water from flue gas via liquid spray columns. Due to ethylene glycol's high boiling point, diffusion-based water recovery is economically favorable compared to distillation-based processes. The following example and flux correlation are taken from the literature source below:\n",
"\n",
"Jennifer Runhong Du, Amit Chakma, X. Feng, Dehydration of ethylene glycol by pervaporation using poly(N,N-dimethylaminoethyl methacrylate)/polysulfone composite membranes, Separation and Purification Technology, Volume 64, Issue 1, 2008, Pages 63-70, ISSN 1383-5866, https://doi.org/10.1016/j.seppur.2008.08.004.\n",
"\n",
@@ -429,7 +429,7 @@
"metadata": {},
"source": [
"## 2.4 Custom Initialization\n",
- "In addition to allowing custom variable and constraint defintions, the Skeleton model enables implementation of a custom initialization scheme. Complex unit operations may present unique tractability issues, and users have precise control over piecewise unit model solving."
+ "In addition to allowing custom variable and constraint definitions, the Skeleton model enables implementation of a custom initialization scheme. Complex unit operations may present unique tractability issues, and users have precise control over piecewise unit model solving."
]
},
{
@@ -724,4 +724,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/operations/skeleton_unit_usr.ipynb b/idaes_examples/notebooks/docs/unit_models/operations/skeleton_unit_usr.ipynb
index 36155c95..9d9adfbe 100644
--- a/idaes_examples/notebooks/docs/unit_models/operations/skeleton_unit_usr.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/operations/skeleton_unit_usr.ipynb
@@ -47,7 +47,7 @@
"\n",
"In many cases, a specific application requires a unique unit operation that does not exist in the IDAES repository. Custom user models may source from external scripts, import surrogate equations or use first-principles calculations. However, IDAES flowsheets adhere to a standardized modeling hierarchy and simple Pyomo models do not always follow these conventions. Additionally, simple flowsheet submodels often require integration with other IDAES unit models which requires consistency between corresponding port variables, stream properties and physical unit sets, as well as proper usage of `ControlVolume` blocks.\n",
"\n",
- "The IDAES `SkeletonUnitModel` allows custom creation of user models blocks that do not require `ControlVolume` blocks, and enabling connection with standard IDAES unit models that do contain `ControlVolume` blocks. To motivate the usefulness and versatility of this tool, we will consider a simple pervaporation unit. The custom model does not require rigourous thermodynamic calculations contained in adjacent unit models, and using a Skeleton model allows definition of only required variables and constraints. The new block does require state variable connections for the inlet and outlet streams. We will demonstrate this scenario below to highlight the usage and benefits of the Skeleton model."
+ "The IDAES `SkeletonUnitModel` allows custom creation of user models blocks that do not require `ControlVolume` blocks, and enabling connection with standard IDAES unit models that do contain `ControlVolume` blocks. To motivate the usefulness and versatility of this tool, we will consider a simple pervaporation unit. The custom model does not require rigorous thermodynamic calculations contained in adjacent unit models, and using a Skeleton model allows definition of only required variables and constraints. The new block does require state variable connections for the inlet and outlet streams. We will demonstrate this scenario below to highlight the usage and benefits of the Skeleton model."
]
},
{
@@ -56,7 +56,7 @@
"source": [
"# 2. Example - Pervaporation\n",
"\n",
- "Pervaporation is a low-energy separation process, and is particularly advantageous over distillation for azeotropic solutions or aqueous mixtures of heavy alcohols. Ethylene glycol is more environmentally friendly than typical chloride- and bromide-based dessicants, and is a common choice for commericial recovery of water from flue gas via liquid spray columns. Due to ethylene glycol's high boiling point, diffusion-based water recovery is economically favorable compared to distillation-based processes. The following example and flux correlation are taken from the literature source below:\n",
+ "Pervaporation is a low-energy separation process, and is particularly advantageous over distillation for azeotropic solutions or aqueous mixtures of heavy alcohols. Ethylene glycol is more environmentally friendly than typical chloride- and bromide-based dessicants, and is a common choice for commercial recovery of water from flue gas via liquid spray columns. Due to ethylene glycol's high boiling point, diffusion-based water recovery is economically favorable compared to distillation-based processes. The following example and flux correlation are taken from the literature source below:\n",
"\n",
"Jennifer Runhong Du, Amit Chakma, X. Feng, Dehydration of ethylene glycol by pervaporation using poly(N,N-dimethylaminoethyl methacrylate)/polysulfone composite membranes, Separation and Purification Technology, Volume 64, Issue 1, 2008, Pages 63-70, ISSN 1383-5866, https://doi.org/10.1016/j.seppur.2008.08.004.\n",
"\n",
@@ -429,7 +429,7 @@
"metadata": {},
"source": [
"## 2.4 Custom Initialization\n",
- "In addition to allowing custom variable and constraint defintions, the Skeleton model enables implementation of a custom initialization scheme. Complex unit operations may present unique tractability issues, and users have precise control over piecewise unit model solving."
+ "In addition to allowing custom variable and constraint definitions, the Skeleton model enables implementation of a custom initialization scheme. Complex unit operations may present unique tractability issues, and users have precise control over piecewise unit model solving."
]
},
{
@@ -724,4 +724,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/operations/turbine.ipynb b/idaes_examples/notebooks/docs/unit_models/operations/turbine.ipynb
index 48bcc8fd..3979dd95 100644
--- a/idaes_examples/notebooks/docs/unit_models/operations/turbine.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/operations/turbine.ipynb
@@ -148,7 +148,7 @@
"# DOF = Number of Model Variables - Number of Model Constraints\n",
"from idaes.core.util.model_statistics import degrees_of_freedom\n",
"\n",
- "# Call the degrees_of_freedom function, get intitial DOF\n",
+ "# Call the degrees_of_freedom function, get initial DOF\n",
"DOF_initial = degrees_of_freedom(m)\n",
"print(\"The initial DOF is {0}\".format(DOF_initial))"
]
@@ -347,7 +347,7 @@
"# Specify that the property package to be used with the turbine is the one we created earlier.\n",
"m.fs.turbine_case_2 = Turbine(property_package=m.fs.properties)\n",
"\n",
- "# Call the degrees_of_freedom function, get intitial DOF\n",
+ "# Call the degrees_of_freedom function, get initial DOF\n",
"DOF_initial = degrees_of_freedom(m.fs.turbine_case_2)\n",
"print(\"The initial DOF is {0}\".format(DOF_initial))"
]
diff --git a/idaes_examples/notebooks/docs/unit_models/operations/turbine_doc.ipynb b/idaes_examples/notebooks/docs/unit_models/operations/turbine_doc.ipynb
index fd3828e2..e2f39fcc 100644
--- a/idaes_examples/notebooks/docs/unit_models/operations/turbine_doc.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/operations/turbine_doc.ipynb
@@ -156,7 +156,7 @@
"# DOF = Number of Model Variables - Number of Model Constraints\n",
"from idaes.core.util.model_statistics import degrees_of_freedom\n",
"\n",
- "# Call the degrees_of_freedom function, get intitial DOF\n",
+ "# Call the degrees_of_freedom function, get initial DOF\n",
"DOF_initial = degrees_of_freedom(m)\n",
"print(\"The initial DOF is {0}\".format(DOF_initial))"
]
@@ -448,7 +448,7 @@
"# Specify that the property package to be used with the turbine is the one we created earlier.\n",
"m.fs.turbine_case_2 = Turbine(property_package=m.fs.properties)\n",
"\n",
- "# Call the degrees_of_freedom function, get intitial DOF\n",
+ "# Call the degrees_of_freedom function, get initial DOF\n",
"DOF_initial = degrees_of_freedom(m.fs.turbine_case_2)\n",
"print(\"The initial DOF is {0}\".format(DOF_initial))"
]
@@ -721,4 +721,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/operations/turbine_test.ipynb b/idaes_examples/notebooks/docs/unit_models/operations/turbine_test.ipynb
index 463e407c..d3fff7d0 100644
--- a/idaes_examples/notebooks/docs/unit_models/operations/turbine_test.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/operations/turbine_test.ipynb
@@ -148,7 +148,7 @@
"# DOF = Number of Model Variables - Number of Model Constraints\n",
"from idaes.core.util.model_statistics import degrees_of_freedom\n",
"\n",
- "# Call the degrees_of_freedom function, get intitial DOF\n",
+ "# Call the degrees_of_freedom function, get initial DOF\n",
"DOF_initial = degrees_of_freedom(m)\n",
"print(\"The initial DOF is {0}\".format(DOF_initial))"
]
@@ -347,7 +347,7 @@
"# Specify that the property package to be used with the turbine is the one we created earlier.\n",
"m.fs.turbine_case_2 = Turbine(property_package=m.fs.properties)\n",
"\n",
- "# Call the degrees_of_freedom function, get intitial DOF\n",
+ "# Call the degrees_of_freedom function, get initial DOF\n",
"DOF_initial = degrees_of_freedom(m.fs.turbine_case_2)\n",
"print(\"The initial DOF is {0}\".format(DOF_initial))"
]
@@ -549,4 +549,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/operations/turbine_usr.ipynb b/idaes_examples/notebooks/docs/unit_models/operations/turbine_usr.ipynb
index ba1eb147..bcebdfef 100644
--- a/idaes_examples/notebooks/docs/unit_models/operations/turbine_usr.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/operations/turbine_usr.ipynb
@@ -148,7 +148,7 @@
"# DOF = Number of Model Variables - Number of Model Constraints\n",
"from idaes.core.util.model_statistics import degrees_of_freedom\n",
"\n",
- "# Call the degrees_of_freedom function, get intitial DOF\n",
+ "# Call the degrees_of_freedom function, get initial DOF\n",
"DOF_initial = degrees_of_freedom(m)\n",
"print(\"The initial DOF is {0}\".format(DOF_initial))"
]
@@ -300,7 +300,7 @@
"# Specify that the property package to be used with the turbine is the one we created earlier.\n",
"m.fs.turbine_case_2 = Turbine(property_package=m.fs.properties)\n",
"\n",
- "# Call the degrees_of_freedom function, get intitial DOF\n",
+ "# Call the degrees_of_freedom function, get initial DOF\n",
"DOF_initial = degrees_of_freedom(m.fs.turbine_case_2)\n",
"print(\"The initial DOF is {0}\".format(DOF_initial))"
]
@@ -440,4 +440,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/reactors/cstr.ipynb b/idaes_examples/notebooks/docs/unit_models/reactors/cstr.ipynb
index d028a0d2..95e99c96 100644
--- a/idaes_examples/notebooks/docs/unit_models/reactors/cstr.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/reactors/cstr.ipynb
@@ -257,7 +257,7 @@
"source": [
"## Connecting Unit Models Using Arcs\n",
"\n",
- "We have now added all the unit models we need to the flowsheet. However, we have not yet specifed how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the `Mixer` to the inlet of the `Heater`, and the outlet of the `Heater` to the inlet of the `CSTR`. Additionally, we will connect the `Feed` and `Product` blocks to the flowsheet:"
+ "We have now added all the unit models we need to the flowsheet. However, we have not yet specified how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the `Mixer` to the inlet of the `Heater`, and the outlet of the `Heater` to the inlet of the `CSTR`. Additionally, we will connect the `Feed` and `Product` blocks to the flowsheet:"
]
},
{
@@ -295,7 +295,7 @@
"source": [
"## Adding Expressions to Compute Operating Costs\n",
"\n",
- "In this section, we will add a few Expressions that allows us to evaluate the performance. `Expressions` provide a convenient way of calculating certain values that are a function of the variables defined in the model. For more details on `Expressions`, please refer to the [Pyomo Expression documentaiton]( https://pyomo.readthedocs.io/en/stable/pyomo_modeling_components/Expressions.html).\n",
+ "In this section, we will add a few Expressions that allows us to evaluate the performance. `Expressions` provide a convenient way of calculating certain values that are a function of the variables defined in the model. For more details on `Expressions`, please refer to the [Pyomo Expression documentation]( https://pyomo.readthedocs.io/en/stable/pyomo_modeling_components/Expressions.html).\n",
"\n",
"For this flowsheet, we are interested in computing ethylene glycol production in millions of pounds per year, as well as the total costs due to cooling and heating utilities."
]
diff --git a/idaes_examples/notebooks/docs/unit_models/reactors/cstr_doc.ipynb b/idaes_examples/notebooks/docs/unit_models/reactors/cstr_doc.ipynb
index b1bc553b..0186ee75 100644
--- a/idaes_examples/notebooks/docs/unit_models/reactors/cstr_doc.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/reactors/cstr_doc.ipynb
@@ -257,7 +257,7 @@
"source": [
"## Connecting Unit Models Using Arcs\n",
"\n",
- "We have now added all the unit models we need to the flowsheet. However, we have not yet specifed how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the `Mixer` to the inlet of the `Heater`, and the outlet of the `Heater` to the inlet of the `CSTR`. Additionally, we will connect the `Feed` and `Product` blocks to the flowsheet:"
+ "We have now added all the unit models we need to the flowsheet. However, we have not yet specified how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the `Mixer` to the inlet of the `Heater`, and the outlet of the `Heater` to the inlet of the `CSTR`. Additionally, we will connect the `Feed` and `Product` blocks to the flowsheet:"
]
},
{
@@ -295,7 +295,7 @@
"source": [
"## Adding Expressions to Compute Operating Costs\n",
"\n",
- "In this section, we will add a few Expressions that allows us to evaluate the performance. `Expressions` provide a convenient way of calculating certain values that are a function of the variables defined in the model. For more details on `Expressions`, please refer to the [Pyomo Expression documentaiton]( https://pyomo.readthedocs.io/en/stable/pyomo_modeling_components/Expressions.html).\n",
+ "In this section, we will add a few Expressions that allows us to evaluate the performance. `Expressions` provide a convenient way of calculating certain values that are a function of the variables defined in the model. For more details on `Expressions`, please refer to the [Pyomo Expression documentation]( https://pyomo.readthedocs.io/en/stable/pyomo_modeling_components/Expressions.html).\n",
"\n",
"For this flowsheet, we are interested in computing ethylene glycol production in millions of pounds per year, as well as the total costs due to cooling and heating utilities."
]
@@ -1251,4 +1251,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/reactors/cstr_test.ipynb b/idaes_examples/notebooks/docs/unit_models/reactors/cstr_test.ipynb
index 46b442c2..517309b5 100644
--- a/idaes_examples/notebooks/docs/unit_models/reactors/cstr_test.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/reactors/cstr_test.ipynb
@@ -54,7 +54,7 @@
"\n",
"Ethylene glycol (EG) is a high-demand chemical, with billions of pounds produced every year for applications such as vehicle anti-freeze. EG may be readily obtained from the hydrolysis of ethylene oxide in the presence of a catalytic intermediate. In this example, an aqueous solution of ethylene oxide hydrolizes after mixing with an aqueous solution of sulfuric acid catalyst:\n",
"\n",
- "**C
2H
4O + H
2O + H
2SO
4 \u2192 C
2H
6O
2 + H
2SO
4**\n",
+ "**C
2H
4O + H
2O + H
2SO
4 → C
2H
6O
2 + H
2SO
4**\n",
"\n",
"This reaction often occurs by two mechanisms, as the catalyst may bind to either reactant before the final hydrolysis step; we will simplify the reaction to a single step for this example.\n",
"\n",
@@ -257,7 +257,7 @@
"source": [
"## Connecting Unit Models Using Arcs\n",
"\n",
- "We have now added all the unit models we need to the flowsheet. However, we have not yet specifed how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the `Mixer` to the inlet of the `Heater`, and the outlet of the `Heater` to the inlet of the `CSTR`. Additionally, we will connect the `Feed` and `Product` blocks to the flowsheet:"
+ "We have now added all the unit models we need to the flowsheet. However, we have not yet specified how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the `Mixer` to the inlet of the `Heater`, and the outlet of the `Heater` to the inlet of the `CSTR`. Additionally, we will connect the `Feed` and `Product` blocks to the flowsheet:"
]
},
{
@@ -295,7 +295,7 @@
"source": [
"## Adding Expressions to Compute Operating Costs\n",
"\n",
- "In this section, we will add a few Expressions that allows us to evaluate the performance. `Expressions` provide a convenient way of calculating certain values that are a function of the variables defined in the model. For more details on `Expressions`, please refer to the [Pyomo Expression documentaiton]( https://pyomo.readthedocs.io/en/stable/pyomo_modeling_components/Expressions.html).\n",
+ "In this section, we will add a few Expressions that allows us to evaluate the performance. `Expressions` provide a convenient way of calculating certain values that are a function of the variables defined in the model. For more details on `Expressions`, please refer to the [Pyomo Expression documentation]( https://pyomo.readthedocs.io/en/stable/pyomo_modeling_components/Expressions.html).\n",
"\n",
"For this flowsheet, we are interested in computing ethylene glycol production in millions of pounds per year, as well as the total costs due to cooling and heating utilities."
]
@@ -856,4 +856,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/reactors/cstr_usr.ipynb b/idaes_examples/notebooks/docs/unit_models/reactors/cstr_usr.ipynb
index 7a73538b..40b3f0a5 100644
--- a/idaes_examples/notebooks/docs/unit_models/reactors/cstr_usr.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/reactors/cstr_usr.ipynb
@@ -54,7 +54,7 @@
"\n",
"Ethylene glycol (EG) is a high-demand chemical, with billions of pounds produced every year for applications such as vehicle anti-freeze. EG may be readily obtained from the hydrolysis of ethylene oxide in the presence of a catalytic intermediate. In this example, an aqueous solution of ethylene oxide hydrolizes after mixing with an aqueous solution of sulfuric acid catalyst:\n",
"\n",
- "**C
2H
4O + H
2O + H
2SO
4 \u2192 C
2H
6O
2 + H
2SO
4**\n",
+ "**C
2H
4O + H
2O + H
2SO
4 → C
2H
6O
2 + H
2SO
4**\n",
"\n",
"This reaction often occurs by two mechanisms, as the catalyst may bind to either reactant before the final hydrolysis step; we will simplify the reaction to a single step for this example.\n",
"\n",
@@ -257,7 +257,7 @@
"source": [
"## Connecting Unit Models Using Arcs\n",
"\n",
- "We have now added all the unit models we need to the flowsheet. However, we have not yet specifed how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the `Mixer` to the inlet of the `Heater`, and the outlet of the `Heater` to the inlet of the `CSTR`. Additionally, we will connect the `Feed` and `Product` blocks to the flowsheet:"
+ "We have now added all the unit models we need to the flowsheet. However, we have not yet specified how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the `Mixer` to the inlet of the `Heater`, and the outlet of the `Heater` to the inlet of the `CSTR`. Additionally, we will connect the `Feed` and `Product` blocks to the flowsheet:"
]
},
{
@@ -295,7 +295,7 @@
"source": [
"## Adding Expressions to Compute Operating Costs\n",
"\n",
- "In this section, we will add a few Expressions that allows us to evaluate the performance. `Expressions` provide a convenient way of calculating certain values that are a function of the variables defined in the model. For more details on `Expressions`, please refer to the [Pyomo Expression documentaiton]( https://pyomo.readthedocs.io/en/stable/pyomo_modeling_components/Expressions.html).\n",
+ "In this section, we will add a few Expressions that allows us to evaluate the performance. `Expressions` provide a convenient way of calculating certain values that are a function of the variables defined in the model. For more details on `Expressions`, please refer to the [Pyomo Expression documentation]( https://pyomo.readthedocs.io/en/stable/pyomo_modeling_components/Expressions.html).\n",
"\n",
"For this flowsheet, we are interested in computing ethylene glycol production in millions of pounds per year, as well as the total costs due to cooling and heating utilities."
]
@@ -722,4 +722,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/reactors/equilibrium_reactor.ipynb b/idaes_examples/notebooks/docs/unit_models/reactors/equilibrium_reactor.ipynb
index 7a95e819..e8b02ceb 100644
--- a/idaes_examples/notebooks/docs/unit_models/reactors/equilibrium_reactor.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/reactors/equilibrium_reactor.ipynb
@@ -63,8 +63,7 @@
"\n",
"The state variables chosen for the property package are **total molar flows of each stream, temperature of each stream and pressure of each stream, and mole fractions of each component in each stream**. The components considered are: **CH
4, H
2O, CO, CO
2, and H
2** and the process occurs in vapor phase only. Therefore, every stream has 1 flow variable, 5 mole fraction variables, 1 temperature and 1 pressure variable. \n",
"\n",
- "\n",
- ""
+ "\n"
]
},
{
@@ -272,7 +271,7 @@
"source": [
"## Connecting Unit Models Using Arcs\n",
"\n",
- "We have now added all the unit models we need to the flowsheet. However, we have not yet specifed how the units are to be connected. To do this, we will be using the `Arc` which is a Pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the `Mixer` to the inlet of the `Compressor`, the outlet of the compressor `Compressor` to the inlet of the `Heater`, and the outlet of the `Heater` to the inlet of the `EquilibriumReactor`. Additionally, we will connect the `Feed` and `Product` blocks to the flowsheet:"
+ "We have now added all the unit models we need to the flowsheet. However, we have not yet specified how the units are to be connected. To do this, we will be using the `Arc` which is a Pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the `Mixer` to the inlet of the `Compressor`, the outlet of the compressor `Compressor` to the inlet of the `Heater`, and the outlet of the `Heater` to the inlet of the `EquilibriumReactor`. Additionally, we will connect the `Feed` and `Product` blocks to the flowsheet:"
]
},
{
diff --git a/idaes_examples/notebooks/docs/unit_models/reactors/equilibrium_reactor_doc.ipynb b/idaes_examples/notebooks/docs/unit_models/reactors/equilibrium_reactor_doc.ipynb
index a0290f0b..0a3935a7 100644
--- a/idaes_examples/notebooks/docs/unit_models/reactors/equilibrium_reactor_doc.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/reactors/equilibrium_reactor_doc.ipynb
@@ -271,7 +271,7 @@
"source": [
"## Connecting Unit Models Using Arcs\n",
"\n",
- "We have now added all the unit models we need to the flowsheet. However, we have not yet specifed how the units are to be connected. To do this, we will be using the `Arc` which is a Pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the `Mixer` to the inlet of the `Compressor`, the outlet of the compressor `Compressor` to the inlet of the `Heater`, and the outlet of the `Heater` to the inlet of the `EquilibriumReactor`. Additionally, we will connect the `Feed` and `Product` blocks to the flowsheet:"
+ "We have now added all the unit models we need to the flowsheet. However, we have not yet specified how the units are to be connected. To do this, we will be using the `Arc` which is a Pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the `Mixer` to the inlet of the `Compressor`, the outlet of the compressor `Compressor` to the inlet of the `Heater`, and the outlet of the `Heater` to the inlet of the `EquilibriumReactor`. Additionally, we will connect the `Feed` and `Product` blocks to the flowsheet:"
]
},
{
@@ -1349,4 +1349,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/reactors/equilibrium_reactor_test.ipynb b/idaes_examples/notebooks/docs/unit_models/reactors/equilibrium_reactor_test.ipynb
index 464604d2..9adb969e 100644
--- a/idaes_examples/notebooks/docs/unit_models/reactors/equilibrium_reactor_test.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/reactors/equilibrium_reactor_test.ipynb
@@ -54,8 +54,8 @@
"\n",
"Steam methane reforming (SMR) is one of the most common pathways for hydrogen production, taking advantage of chemical equilibria in natural gas systems. The process is typically done in two steps: methane reformation at a high temperature to partially oxidize methane, and water gas shift at a low temperature to complete the oxidation reaction:\n",
"\n",
- "**CH
4 + H
2O \u2192 CO + 3H
2** \n",
- "**CO + H
2O \u2192 CO
2 + H
2**\n",
+ "**CH
4 + H
2O → CO + 3H
2** \n",
+ "**CO + H
2O → CO
2 + H
2**\n",
"\n",
"This reaction is often carried out in two separate reactors to allow for different reaction temperatures and pressures; in this example, we will minimize operating cost for a single reactor.\n",
"\n",
@@ -63,8 +63,7 @@
"\n",
"The state variables chosen for the property package are **total molar flows of each stream, temperature of each stream and pressure of each stream, and mole fractions of each component in each stream**. The components considered are: **CH
4, H
2O, CO, CO
2, and H
2** and the process occurs in vapor phase only. Therefore, every stream has 1 flow variable, 5 mole fraction variables, 1 temperature and 1 pressure variable. \n",
"\n",
- "\n",
- ""
+ "\n"
]
},
{
@@ -272,7 +271,7 @@
"source": [
"## Connecting Unit Models Using Arcs\n",
"\n",
- "We have now added all the unit models we need to the flowsheet. However, we have not yet specifed how the units are to be connected. To do this, we will be using the `Arc` which is a Pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the `Mixer` to the inlet of the `Compressor`, the outlet of the compressor `Compressor` to the inlet of the `Heater`, and the outlet of the `Heater` to the inlet of the `EquilibriumReactor`. Additionally, we will connect the `Feed` and `Product` blocks to the flowsheet:"
+ "We have now added all the unit models we need to the flowsheet. However, we have not yet specified how the units are to be connected. To do this, we will be using the `Arc` which is a Pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the `Mixer` to the inlet of the `Compressor`, the outlet of the compressor `Compressor` to the inlet of the `Heater`, and the outlet of the `Heater` to the inlet of the `EquilibriumReactor`. Additionally, we will connect the `Feed` and `Product` blocks to the flowsheet:"
]
},
{
@@ -867,4 +866,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/reactors/equilibrium_reactor_usr.ipynb b/idaes_examples/notebooks/docs/unit_models/reactors/equilibrium_reactor_usr.ipynb
index 90cc9c29..20b6e5a8 100644
--- a/idaes_examples/notebooks/docs/unit_models/reactors/equilibrium_reactor_usr.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/reactors/equilibrium_reactor_usr.ipynb
@@ -54,8 +54,8 @@
"\n",
"Steam methane reforming (SMR) is one of the most common pathways for hydrogen production, taking advantage of chemical equilibria in natural gas systems. The process is typically done in two steps: methane reformation at a high temperature to partially oxidize methane, and water gas shift at a low temperature to complete the oxidation reaction:\n",
"\n",
- "**CH
4 + H
2O \u2192 CO + 3H
2** \n",
- "**CO + H
2O \u2192 CO
2 + H
2**\n",
+ "**CH
4 + H
2O → CO + 3H
2** \n",
+ "**CO + H
2O → CO
2 + H
2**\n",
"\n",
"This reaction is often carried out in two separate reactors to allow for different reaction temperatures and pressures; in this example, we will minimize operating cost for a single reactor.\n",
"\n",
@@ -63,8 +63,7 @@
"\n",
"The state variables chosen for the property package are **total molar flows of each stream, temperature of each stream and pressure of each stream, and mole fractions of each component in each stream**. The components considered are: **CH
4, H
2O, CO, CO
2, and H
2** and the process occurs in vapor phase only. Therefore, every stream has 1 flow variable, 5 mole fraction variables, 1 temperature and 1 pressure variable. \n",
"\n",
- "\n",
- ""
+ "\n"
]
},
{
@@ -272,7 +271,7 @@
"source": [
"## Connecting Unit Models Using Arcs\n",
"\n",
- "We have now added all the unit models we need to the flowsheet. However, we have not yet specifed how the units are to be connected. To do this, we will be using the `Arc` which is a Pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the `Mixer` to the inlet of the `Compressor`, the outlet of the compressor `Compressor` to the inlet of the `Heater`, and the outlet of the `Heater` to the inlet of the `EquilibriumReactor`. Additionally, we will connect the `Feed` and `Product` blocks to the flowsheet:"
+ "We have now added all the unit models we need to the flowsheet. However, we have not yet specified how the units are to be connected. To do this, we will be using the `Arc` which is a Pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the `Mixer` to the inlet of the `Compressor`, the outlet of the compressor `Compressor` to the inlet of the `Heater`, and the outlet of the `Heater` to the inlet of the `EquilibriumReactor`. Additionally, we will connect the `Feed` and `Product` blocks to the flowsheet:"
]
},
{
@@ -733,4 +732,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/reactors/plug_flow_reactor.ipynb b/idaes_examples/notebooks/docs/unit_models/reactors/plug_flow_reactor.ipynb
index 8b0887c1..2fe06cf1 100644
--- a/idaes_examples/notebooks/docs/unit_models/reactors/plug_flow_reactor.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/reactors/plug_flow_reactor.ipynb
@@ -53,7 +53,7 @@
"\n",
"Chemical reaction:\n",
"\n",
- "**C
2H
4O + H
2O + H
2SO
4 \u2192 C
2H
6O
2 + H
2SO
4**\n",
+ "**C
2H
4O + H
2O + H
2SO
4 → C
2H
6O
2 + H
2SO
4**\n",
"\n",
"Property Packages:\n",
"\n",
@@ -256,7 +256,7 @@
"source": [
"## Connecting Unit Models Using Arcs\n",
"\n",
- "We have now added all the unit models we need to the flowsheet. However, we have not yet specifed how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the `Mixer` to the inlet of the `Heater`, and the outlet of the `Heater` to the inlet of the `PFR`. Additionally, we will connect the `Feed` and `Product` blocks to the flowsheet:"
+ "We have now added all the unit models we need to the flowsheet. However, we have not yet specified how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the `Mixer` to the inlet of the `Heater`, and the outlet of the `Heater` to the inlet of the `PFR`. Additionally, we will connect the `Feed` and `Product` blocks to the flowsheet:"
]
},
{
@@ -294,7 +294,7 @@
"source": [
"## Adding Expressions to Compute Operating Costs\n",
"\n",
- "In this section, we will add a few Expressions that allows us to evaluate the performance. `Expressions` provide a convenient way of calculating certain values that are a function of the variables defined in the model. For more details on `Expressions`, please refer to the [Pyomo Expression documentaiton]( https://pyomo.readthedocs.io/en/stable/pyomo_modeling_components/Expressions.html).\n",
+ "In this section, we will add a few Expressions that allows us to evaluate the performance. `Expressions` provide a convenient way of calculating certain values that are a function of the variables defined in the model. For more details on `Expressions`, please refer to the [Pyomo Expression documentation]( https://pyomo.readthedocs.io/en/stable/pyomo_modeling_components/Expressions.html).\n",
"\n",
"For this flowsheet, we are interested in computing ethylene glycol production in millions of pounds per year, as well as the total costs due to cooling and heating utilities."
]
@@ -977,4 +977,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/reactors/plug_flow_reactor_doc.ipynb b/idaes_examples/notebooks/docs/unit_models/reactors/plug_flow_reactor_doc.ipynb
index 5e4b7f03..3ecaff51 100644
--- a/idaes_examples/notebooks/docs/unit_models/reactors/plug_flow_reactor_doc.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/reactors/plug_flow_reactor_doc.ipynb
@@ -256,7 +256,7 @@
"source": [
"## Connecting Unit Models Using Arcs\n",
"\n",
- "We have now added all the unit models we need to the flowsheet. However, we have not yet specifed how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the `Mixer` to the inlet of the `Heater`, and the outlet of the `Heater` to the inlet of the `PFR`. Additionally, we will connect the `Feed` and `Product` blocks to the flowsheet:"
+ "We have now added all the unit models we need to the flowsheet. However, we have not yet specified how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the `Mixer` to the inlet of the `Heater`, and the outlet of the `Heater` to the inlet of the `PFR`. Additionally, we will connect the `Feed` and `Product` blocks to the flowsheet:"
]
},
{
@@ -294,7 +294,7 @@
"source": [
"## Adding Expressions to Compute Operating Costs\n",
"\n",
- "In this section, we will add a few Expressions that allows us to evaluate the performance. `Expressions` provide a convenient way of calculating certain values that are a function of the variables defined in the model. For more details on `Expressions`, please refer to the [Pyomo Expression documentaiton]( https://pyomo.readthedocs.io/en/stable/pyomo_modeling_components/Expressions.html).\n",
+ "In this section, we will add a few Expressions that allows us to evaluate the performance. `Expressions` provide a convenient way of calculating certain values that are a function of the variables defined in the model. For more details on `Expressions`, please refer to the [Pyomo Expression documentation]( https://pyomo.readthedocs.io/en/stable/pyomo_modeling_components/Expressions.html).\n",
"\n",
"For this flowsheet, we are interested in computing ethylene glycol production in millions of pounds per year, as well as the total costs due to cooling and heating utilities."
]
@@ -1337,4 +1337,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/reactors/plug_flow_reactor_test.ipynb b/idaes_examples/notebooks/docs/unit_models/reactors/plug_flow_reactor_test.ipynb
index 299620c2..dcfe84f8 100644
--- a/idaes_examples/notebooks/docs/unit_models/reactors/plug_flow_reactor_test.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/reactors/plug_flow_reactor_test.ipynb
@@ -53,7 +53,7 @@
"\n",
"Chemical reaction:\n",
"\n",
- "**C
2H
4O + H
2O + H
2SO
4 \u2192 C
2H
6O
2 + H
2SO
4**\n",
+ "**C
2H
4O + H
2O + H
2SO
4 → C
2H
6O
2 + H
2SO
4**\n",
"\n",
"Property Packages:\n",
"\n",
@@ -256,7 +256,7 @@
"source": [
"## Connecting Unit Models Using Arcs\n",
"\n",
- "We have now added all the unit models we need to the flowsheet. However, we have not yet specifed how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the `Mixer` to the inlet of the `Heater`, and the outlet of the `Heater` to the inlet of the `PFR`. Additionally, we will connect the `Feed` and `Product` blocks to the flowsheet:"
+ "We have now added all the unit models we need to the flowsheet. However, we have not yet specified how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the `Mixer` to the inlet of the `Heater`, and the outlet of the `Heater` to the inlet of the `PFR`. Additionally, we will connect the `Feed` and `Product` blocks to the flowsheet:"
]
},
{
@@ -294,7 +294,7 @@
"source": [
"## Adding Expressions to Compute Operating Costs\n",
"\n",
- "In this section, we will add a few Expressions that allows us to evaluate the performance. `Expressions` provide a convenient way of calculating certain values that are a function of the variables defined in the model. For more details on `Expressions`, please refer to the [Pyomo Expression documentaiton]( https://pyomo.readthedocs.io/en/stable/pyomo_modeling_components/Expressions.html).\n",
+ "In this section, we will add a few Expressions that allows us to evaluate the performance. `Expressions` provide a convenient way of calculating certain values that are a function of the variables defined in the model. For more details on `Expressions`, please refer to the [Pyomo Expression documentation]( https://pyomo.readthedocs.io/en/stable/pyomo_modeling_components/Expressions.html).\n",
"\n",
"For this flowsheet, we are interested in computing ethylene glycol production in millions of pounds per year, as well as the total costs due to cooling and heating utilities."
]
@@ -977,4 +977,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/reactors/plug_flow_reactor_usr.ipynb b/idaes_examples/notebooks/docs/unit_models/reactors/plug_flow_reactor_usr.ipynb
index 5253a423..b0473332 100644
--- a/idaes_examples/notebooks/docs/unit_models/reactors/plug_flow_reactor_usr.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/reactors/plug_flow_reactor_usr.ipynb
@@ -53,7 +53,7 @@
"\n",
"Chemical reaction:\n",
"\n",
- "**C
2H
4O + H
2O + H
2SO
4 \u2192 C
2H
6O
2 + H
2SO
4**\n",
+ "**C
2H
4O + H
2O + H
2SO
4 → C
2H
6O
2 + H
2SO
4**\n",
"\n",
"Property Packages:\n",
"\n",
@@ -256,7 +256,7 @@
"source": [
"## Connecting Unit Models Using Arcs\n",
"\n",
- "We have now added all the unit models we need to the flowsheet. However, we have not yet specifed how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the `Mixer` to the inlet of the `Heater`, and the outlet of the `Heater` to the inlet of the `PFR`. Additionally, we will connect the `Feed` and `Product` blocks to the flowsheet:"
+ "We have now added all the unit models we need to the flowsheet. However, we have not yet specified how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the `Mixer` to the inlet of the `Heater`, and the outlet of the `Heater` to the inlet of the `PFR`. Additionally, we will connect the `Feed` and `Product` blocks to the flowsheet:"
]
},
{
@@ -294,7 +294,7 @@
"source": [
"## Adding Expressions to Compute Operating Costs\n",
"\n",
- "In this section, we will add a few Expressions that allows us to evaluate the performance. `Expressions` provide a convenient way of calculating certain values that are a function of the variables defined in the model. For more details on `Expressions`, please refer to the [Pyomo Expression documentaiton]( https://pyomo.readthedocs.io/en/stable/pyomo_modeling_components/Expressions.html).\n",
+ "In this section, we will add a few Expressions that allows us to evaluate the performance. `Expressions` provide a convenient way of calculating certain values that are a function of the variables defined in the model. For more details on `Expressions`, please refer to the [Pyomo Expression documentation]( https://pyomo.readthedocs.io/en/stable/pyomo_modeling_components/Expressions.html).\n",
"\n",
"For this flowsheet, we are interested in computing ethylene glycol production in millions of pounds per year, as well as the total costs due to cooling and heating utilities."
]
@@ -806,4 +806,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/reactors/stoichiometric_reactor.ipynb b/idaes_examples/notebooks/docs/unit_models/reactors/stoichiometric_reactor.ipynb
index 68e2729a..c12fd541 100644
--- a/idaes_examples/notebooks/docs/unit_models/reactors/stoichiometric_reactor.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/reactors/stoichiometric_reactor.ipynb
@@ -62,8 +62,7 @@
"\n",
"Flowsheet:\n",
"\n",
- "\n",
- ""
+ "\n"
]
},
{
@@ -240,7 +239,7 @@
"source": [
"## Connecting Unit Models Using Arcs\n",
"\n",
- "We have now added all the unit models we need to the flowsheet. However, we have not yet specifed how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the `Mixer` to the inlet of the `Heater`, and the outlet of the `Heater` to the inlet of the `StoichiometricReactor`. Additionally, we will connect the `Feed` and `Product` blocks to the flowsheet:"
+ "We have now added all the unit models we need to the flowsheet. However, we have not yet specified how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the `Mixer` to the inlet of the `Heater`, and the outlet of the `Heater` to the inlet of the `StoichiometricReactor`. Additionally, we will connect the `Feed` and `Product` blocks to the flowsheet:"
]
},
{
@@ -278,7 +277,7 @@
"source": [
"## Adding Expressions to Compute Operating Costs\n",
"\n",
- "In this section, we will add a few Expressions that allows us to evaluate the performance. `Expressions` provide a convenient way of calculating certain values that are a function of the variables defined in the model. For more details on `Expressions`, please refer to the [Pyomo Expression documentaiton]( https://pyomo.readthedocs.io/en/stable/pyomo_modeling_components/Expressions.html).\n",
+ "In this section, we will add a few Expressions that allows us to evaluate the performance. `Expressions` provide a convenient way of calculating certain values that are a function of the variables defined in the model. For more details on `Expressions`, please refer to the [Pyomo Expression documentation]( https://pyomo.readthedocs.io/en/stable/pyomo_modeling_components/Expressions.html).\n",
"\n",
"For this flowsheet, we are interested in computing ethylene glycol production in millions of pounds per year, as well as the total costs due to cooling and heating utilities."
]
diff --git a/idaes_examples/notebooks/docs/unit_models/reactors/stoichiometric_reactor_doc.ipynb b/idaes_examples/notebooks/docs/unit_models/reactors/stoichiometric_reactor_doc.ipynb
index 9d4995aa..d7b699c7 100644
--- a/idaes_examples/notebooks/docs/unit_models/reactors/stoichiometric_reactor_doc.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/reactors/stoichiometric_reactor_doc.ipynb
@@ -239,7 +239,7 @@
"source": [
"## Connecting Unit Models Using Arcs\n",
"\n",
- "We have now added all the unit models we need to the flowsheet. However, we have not yet specifed how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the `Mixer` to the inlet of the `Heater`, and the outlet of the `Heater` to the inlet of the `StoichiometricReactor`. Additionally, we will connect the `Feed` and `Product` blocks to the flowsheet:"
+ "We have now added all the unit models we need to the flowsheet. However, we have not yet specified how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the `Mixer` to the inlet of the `Heater`, and the outlet of the `Heater` to the inlet of the `StoichiometricReactor`. Additionally, we will connect the `Feed` and `Product` blocks to the flowsheet:"
]
},
{
@@ -277,7 +277,7 @@
"source": [
"## Adding Expressions to Compute Operating Costs\n",
"\n",
- "In this section, we will add a few Expressions that allows us to evaluate the performance. `Expressions` provide a convenient way of calculating certain values that are a function of the variables defined in the model. For more details on `Expressions`, please refer to the [Pyomo Expression documentaiton]( https://pyomo.readthedocs.io/en/stable/pyomo_modeling_components/Expressions.html).\n",
+ "In this section, we will add a few Expressions that allows us to evaluate the performance. `Expressions` provide a convenient way of calculating certain values that are a function of the variables defined in the model. For more details on `Expressions`, please refer to the [Pyomo Expression documentation]( https://pyomo.readthedocs.io/en/stable/pyomo_modeling_components/Expressions.html).\n",
"\n",
"For this flowsheet, we are interested in computing ethylene glycol production in millions of pounds per year, as well as the total costs due to cooling and heating utilities."
]
@@ -1207,4 +1207,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/reactors/stoichiometric_reactor_test.ipynb b/idaes_examples/notebooks/docs/unit_models/reactors/stoichiometric_reactor_test.ipynb
index cf48355a..6ae99dc8 100644
--- a/idaes_examples/notebooks/docs/unit_models/reactors/stoichiometric_reactor_test.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/reactors/stoichiometric_reactor_test.ipynb
@@ -53,7 +53,7 @@
"\n",
"Chemical reaction:\n",
"\n",
- "**C
2H
4O + H
2O + H
2SO
4 \u2192 C
2H
6O
2 + H
2SO
4**\n",
+ "**C
2H
4O + H
2O + H
2SO
4 → C
2H
6O
2 + H
2SO
4**\n",
"\n",
"Property Packages:\n",
"\n",
@@ -62,8 +62,7 @@
"\n",
"Flowsheet:\n",
"\n",
- "\n",
- ""
+ "\n"
]
},
{
@@ -240,7 +239,7 @@
"source": [
"## Connecting Unit Models Using Arcs\n",
"\n",
- "We have now added all the unit models we need to the flowsheet. However, we have not yet specifed how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the `Mixer` to the inlet of the `Heater`, and the outlet of the `Heater` to the inlet of the `StoichiometricReactor`. Additionally, we will connect the `Feed` and `Product` blocks to the flowsheet:"
+ "We have now added all the unit models we need to the flowsheet. However, we have not yet specified how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the `Mixer` to the inlet of the `Heater`, and the outlet of the `Heater` to the inlet of the `StoichiometricReactor`. Additionally, we will connect the `Feed` and `Product` blocks to the flowsheet:"
]
},
{
@@ -278,7 +277,7 @@
"source": [
"## Adding Expressions to Compute Operating Costs\n",
"\n",
- "In this section, we will add a few Expressions that allows us to evaluate the performance. `Expressions` provide a convenient way of calculating certain values that are a function of the variables defined in the model. For more details on `Expressions`, please refer to the [Pyomo Expression documentaiton]( https://pyomo.readthedocs.io/en/stable/pyomo_modeling_components/Expressions.html).\n",
+ "In this section, we will add a few Expressions that allows us to evaluate the performance. `Expressions` provide a convenient way of calculating certain values that are a function of the variables defined in the model. For more details on `Expressions`, please refer to the [Pyomo Expression documentation]( https://pyomo.readthedocs.io/en/stable/pyomo_modeling_components/Expressions.html).\n",
"\n",
"For this flowsheet, we are interested in computing ethylene glycol production in millions of pounds per year, as well as the total costs due to cooling and heating utilities."
]
@@ -825,4 +824,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/docs/unit_models/reactors/stoichiometric_reactor_usr.ipynb b/idaes_examples/notebooks/docs/unit_models/reactors/stoichiometric_reactor_usr.ipynb
index ee24e013..06425641 100644
--- a/idaes_examples/notebooks/docs/unit_models/reactors/stoichiometric_reactor_usr.ipynb
+++ b/idaes_examples/notebooks/docs/unit_models/reactors/stoichiometric_reactor_usr.ipynb
@@ -53,7 +53,7 @@
"\n",
"Chemical reaction:\n",
"\n",
- "**C
2H
4O + H
2O + H
2SO
4 \u2192 C
2H
6O
2 + H
2SO
4**\n",
+ "**C
2H
4O + H
2O + H
2SO
4 → C
2H
6O
2 + H
2SO
4**\n",
"\n",
"Property Packages:\n",
"\n",
@@ -62,8 +62,7 @@
"\n",
"Flowsheet:\n",
"\n",
- "\n",
- ""
+ "\n"
]
},
{
@@ -240,7 +239,7 @@
"source": [
"## Connecting Unit Models Using Arcs\n",
"\n",
- "We have now added all the unit models we need to the flowsheet. However, we have not yet specifed how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the `Mixer` to the inlet of the `Heater`, and the outlet of the `Heater` to the inlet of the `StoichiometricReactor`. Additionally, we will connect the `Feed` and `Product` blocks to the flowsheet:"
+ "We have now added all the unit models we need to the flowsheet. However, we have not yet specified how the units are to be connected. To do this, we will be using the `Arc` which is a pyomo component that takes in two arguments: `source` and `destination`. Let us connect the outlet of the `Mixer` to the inlet of the `Heater`, and the outlet of the `Heater` to the inlet of the `StoichiometricReactor`. Additionally, we will connect the `Feed` and `Product` blocks to the flowsheet:"
]
},
{
@@ -278,7 +277,7 @@
"source": [
"## Adding Expressions to Compute Operating Costs\n",
"\n",
- "In this section, we will add a few Expressions that allows us to evaluate the performance. `Expressions` provide a convenient way of calculating certain values that are a function of the variables defined in the model. For more details on `Expressions`, please refer to the [Pyomo Expression documentaiton]( https://pyomo.readthedocs.io/en/stable/pyomo_modeling_components/Expressions.html).\n",
+ "In this section, we will add a few Expressions that allows us to evaluate the performance. `Expressions` provide a convenient way of calculating certain values that are a function of the variables defined in the model. For more details on `Expressions`, please refer to the [Pyomo Expression documentation]( https://pyomo.readthedocs.io/en/stable/pyomo_modeling_components/Expressions.html).\n",
"\n",
"For this flowsheet, we are interested in computing ethylene glycol production in millions of pounds per year, as well as the total costs due to cooling and heating utilities."
]
@@ -693,4 +692,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/held/flowsheets/CO2_adsorption_desorption/CO2_Adsorption_Desorption_1DFixedBed.ipynb b/idaes_examples/notebooks/held/flowsheets/CO2_adsorption_desorption/CO2_Adsorption_Desorption_1DFixedBed.ipynb
index 750ef5c6..f90e547b 100644
--- a/idaes_examples/notebooks/held/flowsheets/CO2_adsorption_desorption/CO2_Adsorption_Desorption_1DFixedBed.ipynb
+++ b/idaes_examples/notebooks/held/flowsheets/CO2_adsorption_desorption/CO2_Adsorption_Desorption_1DFixedBed.ipynb
@@ -107,7 +107,7 @@
"metadata": {},
"source": [
"\n",
- "### Import Pyomo pakages\n",
+ "### Import Pyomo packages\n",
"For the flowsheet, we will need several components from the pyomo libraries.\n",
"\n",
"- ConcreteModel (to create the Pyomo model that will contain the IDAES flowsheet)\n",
@@ -493,7 +493,9 @@
"cell_type": "code",
"execution_count": 11,
"metadata": {
- "tags": ["testing"]
+ "tags": [
+ "testing"
+ ]
},
"outputs": [],
"source": [
@@ -701,7 +703,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "In the temporal plots below, quantities are reported as functions of time and contoured for six points along the length of the bed. The time and spatial dimensions are exchanged in the spatial plots, with quantities reported as functions of lengh and contoured for five time points.\n",
+ "In the temporal plots below, quantities are reported as functions of time and contoured for six points along the length of the bed. The time and spatial dimensions are exchanged in the spatial plots, with quantities reported as functions of length and contoured for five time points.\n",
"\n",
"The gas flowrate is constant at the inlet and decreases over the length of the bed as CO2 is removed from the gas. At each spatial point, the CO2 content of the gas increases over time as the bed becomes more saturated with CO2 and the mass transfer driving force decreases. Assessing the two gas flowrate plots, adsorption occurs steadily over time with a much larger capture rate in the initial spatial region; this region grows from 10% to 25% of the bed length as the bed becomes more saturated with CO2 over time.\n",
"\n",
@@ -999,7 +1001,7 @@
"\n",
"The CO2 content of the gas sharply rises initially, and steadily decreases as CO2 is carried away in the sweep gas. A greater amount of CO2 is recovered closer to the reactor inlet. As the sweep gas is nearly pure water vapor, the water concentration in the gas sharply drops as CO2 is desorbed from the bed and recovers to near unity towards the temporal end of the simulation.\n",
"\n",
- "Carbamate disappears quickly as CO2 is recovered and the hydrate is broken down, occuring evenly across the length of the reactor bed."
+ "Carbamate disappears quickly as CO2 is recovered and the hydrate is broken down, occurring evenly across the length of the reactor bed."
]
},
{
diff --git a/idaes_examples/notebooks/held/flowsheets/CO2_adsorption_desorption/CO2_Adsorption_Desorption_1DFixedBed_doc.ipynb b/idaes_examples/notebooks/held/flowsheets/CO2_adsorption_desorption/CO2_Adsorption_Desorption_1DFixedBed_doc.ipynb
index 9a67262c..8440fb43 100644
--- a/idaes_examples/notebooks/held/flowsheets/CO2_adsorption_desorption/CO2_Adsorption_Desorption_1DFixedBed_doc.ipynb
+++ b/idaes_examples/notebooks/held/flowsheets/CO2_adsorption_desorption/CO2_Adsorption_Desorption_1DFixedBed_doc.ipynb
@@ -36,7 +36,7 @@
"
\n",
"\n",
"This jupyter notebook shows an example of a CO2 Adsorption Desorption cycle with the IDAES 1D FixedBed model. The IDAES 1D FixedBed model is a dynamic and axially varying reactor/adsorption model which is able to model the gas and solid interactions of the modeled species in detail. The sorbent used for this example is the NETL_32D sorbent with its details and parameters obtained from the following references: \n",
- "- A. Lee, D.C. Miller, A One-Dimensional (1-D) Three-Region Model for a Bubbling Fluidized-Bed Adsorber, Ind. Eng. Chem. Res. 52 (2013) 469\u2013484\n",
+ "- A. Lee, D.C. Miller, A One-Dimensional (1-D) Three-Region Model for a Bubbling Fluidized-Bed Adsorber, Ind. Eng. Chem. Res. 52 (2013) 469–484\n",
"- Lee, A.; Mebane, D.; Fauth, D. J.; Miller, D. C. A Model for the Adsorption Kinetics of CO2 on Amine-Impregnated Mesoporous Sorbents in the Presence of Water. Presented at the 28th International Pittsburgh Coal Conference, Pittsburgh, PA, 2011.\n",
"\n",
"The notebook demonstrates how to use the IDAES 1DFixedBed model for an adsorption/desorption application with distinct adsorption and desorption steps. This example leverages custom libraries and functions specific to the NETL_32D solid sorbent and associated gas phase properties and surface reactions. In this system, the silicon monoxide (SiO(s)) sorbent reduces carbon dioxide (CO2(g)) to carbamate (denoted Car(s)) while simultaneously absorbing water vapor (H2O(g)) to produce a solid solution-state hydrate (H2O(s)). The solid phase is considered a one-dimensional domain with three regions for bubble, cloud wake and emulsion properties for bubbling bed systems; in the case of a fixed bed reactor non-bulk gas behavior is neglected and assumed to be homogeneous everywhere not near the solid surface.\n",
@@ -107,7 +107,7 @@
"metadata": {},
"source": [
"\n",
- "### Import Pyomo pakages\n",
+ "### Import Pyomo packages\n",
"For the flowsheet, we will need several components from the pyomo libraries.\n",
"\n",
"- ConcreteModel (to create the Pyomo model that will contain the IDAES flowsheet)\n",
@@ -689,7 +689,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "In the temporal plots below, quantities are reported as functions of time and contoured for six points along the length of the bed. The time and spatial dimensions are exchanged in the spatial plots, with quantities reported as functions of lengh and contoured for five time points.\n",
+ "In the temporal plots below, quantities are reported as functions of time and contoured for six points along the length of the bed. The time and spatial dimensions are exchanged in the spatial plots, with quantities reported as functions of length and contoured for five time points.\n",
"\n",
"The gas flowrate is constant at the inlet and decreases over the length of the bed as CO2 is removed from the gas. At each spatial point, the CO2 content of the gas increases over time as the bed becomes more saturated with CO2 and the mass transfer driving force decreases. Assessing the two gas flowrate plots, adsorption occurs steadily over time with a much larger capture rate in the initial spatial region; this region grows from 10% to 25% of the bed length as the bed becomes more saturated with CO2 over time.\n",
"\n",
@@ -987,7 +987,7 @@
"\n",
"The CO2 content of the gas sharply rises initially, and steadily decreases as CO2 is carried away in the sweep gas. A greater amount of CO2 is recovered closer to the reactor inlet. As the sweep gas is nearly pure water vapor, the water concentration in the gas sharply drops as CO2 is desorbed from the bed and recovers to near unity towards the temporal end of the simulation.\n",
"\n",
- "Carbamate disappears quickly as CO2 is recovered and the hydrate is broken down, occuring evenly across the length of the reactor bed."
+ "Carbamate disappears quickly as CO2 is recovered and the hydrate is broken down, occurring evenly across the length of the reactor bed."
]
},
{
@@ -1109,4 +1109,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/held/flowsheets/CO2_adsorption_desorption/CO2_Adsorption_Desorption_1DFixedBed_test.ipynb b/idaes_examples/notebooks/held/flowsheets/CO2_adsorption_desorption/CO2_Adsorption_Desorption_1DFixedBed_test.ipynb
index 28855348..0b57769a 100644
--- a/idaes_examples/notebooks/held/flowsheets/CO2_adsorption_desorption/CO2_Adsorption_Desorption_1DFixedBed_test.ipynb
+++ b/idaes_examples/notebooks/held/flowsheets/CO2_adsorption_desorption/CO2_Adsorption_Desorption_1DFixedBed_test.ipynb
@@ -36,7 +36,7 @@
"
\n",
"\n",
"This jupyter notebook shows an example of a CO2 Adsorption Desorption cycle with the IDAES 1D FixedBed model. The IDAES 1D FixedBed model is a dynamic and axially varying reactor/adsorption model which is able to model the gas and solid interactions of the modeled species in detail. The sorbent used for this example is the NETL_32D sorbent with its details and parameters obtained from the following references: \n",
- "- A. Lee, D.C. Miller, A One-Dimensional (1-D) Three-Region Model for a Bubbling Fluidized-Bed Adsorber, Ind. Eng. Chem. Res. 52 (2013) 469\u2013484\n",
+ "- A. Lee, D.C. Miller, A One-Dimensional (1-D) Three-Region Model for a Bubbling Fluidized-Bed Adsorber, Ind. Eng. Chem. Res. 52 (2013) 469–484\n",
"- Lee, A.; Mebane, D.; Fauth, D. J.; Miller, D. C. A Model for the Adsorption Kinetics of CO2 on Amine-Impregnated Mesoporous Sorbents in the Presence of Water. Presented at the 28th International Pittsburgh Coal Conference, Pittsburgh, PA, 2011.\n",
"\n",
"The notebook demonstrates how to use the IDAES 1DFixedBed model for an adsorption/desorption application with distinct adsorption and desorption steps. This example leverages custom libraries and functions specific to the NETL_32D solid sorbent and associated gas phase properties and surface reactions. In this system, the silicon monoxide (SiO(s)) sorbent reduces carbon dioxide (CO2(g)) to carbamate (denoted Car(s)) while simultaneously absorbing water vapor (H2O(g)) to produce a solid solution-state hydrate (H2O(s)). The solid phase is considered a one-dimensional domain with three regions for bubble, cloud wake and emulsion properties for bubbling bed systems; in the case of a fixed bed reactor non-bulk gas behavior is neglected and assumed to be homogeneous everywhere not near the solid surface.\n",
@@ -107,7 +107,7 @@
"metadata": {},
"source": [
"\n",
- "### Import Pyomo pakages\n",
+ "### Import Pyomo packages\n",
"For the flowsheet, we will need several components from the pyomo libraries.\n",
"\n",
"- ConcreteModel (to create the Pyomo model that will contain the IDAES flowsheet)\n",
@@ -703,7 +703,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "In the temporal plots below, quantities are reported as functions of time and contoured for six points along the length of the bed. The time and spatial dimensions are exchanged in the spatial plots, with quantities reported as functions of lengh and contoured for five time points.\n",
+ "In the temporal plots below, quantities are reported as functions of time and contoured for six points along the length of the bed. The time and spatial dimensions are exchanged in the spatial plots, with quantities reported as functions of length and contoured for five time points.\n",
"\n",
"The gas flowrate is constant at the inlet and decreases over the length of the bed as CO2 is removed from the gas. At each spatial point, the CO2 content of the gas increases over time as the bed becomes more saturated with CO2 and the mass transfer driving force decreases. Assessing the two gas flowrate plots, adsorption occurs steadily over time with a much larger capture rate in the initial spatial region; this region grows from 10% to 25% of the bed length as the bed becomes more saturated with CO2 over time.\n",
"\n",
@@ -1001,7 +1001,7 @@
"\n",
"The CO2 content of the gas sharply rises initially, and steadily decreases as CO2 is carried away in the sweep gas. A greater amount of CO2 is recovered closer to the reactor inlet. As the sweep gas is nearly pure water vapor, the water concentration in the gas sharply drops as CO2 is desorbed from the bed and recovers to near unity towards the temporal end of the simulation.\n",
"\n",
- "Carbamate disappears quickly as CO2 is recovered and the hydrate is broken down, occuring evenly across the length of the reactor bed."
+ "Carbamate disappears quickly as CO2 is recovered and the hydrate is broken down, occurring evenly across the length of the reactor bed."
]
},
{
@@ -1123,4 +1123,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/idaes_examples/notebooks/held/flowsheets/CO2_adsorption_desorption/CO2_Adsorption_Desorption_1DFixedBed_usr.ipynb b/idaes_examples/notebooks/held/flowsheets/CO2_adsorption_desorption/CO2_Adsorption_Desorption_1DFixedBed_usr.ipynb
index 9a67262c..8440fb43 100644
--- a/idaes_examples/notebooks/held/flowsheets/CO2_adsorption_desorption/CO2_Adsorption_Desorption_1DFixedBed_usr.ipynb
+++ b/idaes_examples/notebooks/held/flowsheets/CO2_adsorption_desorption/CO2_Adsorption_Desorption_1DFixedBed_usr.ipynb
@@ -36,7 +36,7 @@
"
\n",
"\n",
"This jupyter notebook shows an example of a CO2 Adsorption Desorption cycle with the IDAES 1D FixedBed model. The IDAES 1D FixedBed model is a dynamic and axially varying reactor/adsorption model which is able to model the gas and solid interactions of the modeled species in detail. The sorbent used for this example is the NETL_32D sorbent with its details and parameters obtained from the following references: \n",
- "- A. Lee, D.C. Miller, A One-Dimensional (1-D) Three-Region Model for a Bubbling Fluidized-Bed Adsorber, Ind. Eng. Chem. Res. 52 (2013) 469\u2013484\n",
+ "- A. Lee, D.C. Miller, A One-Dimensional (1-D) Three-Region Model for a Bubbling Fluidized-Bed Adsorber, Ind. Eng. Chem. Res. 52 (2013) 469–484\n",
"- Lee, A.; Mebane, D.; Fauth, D. J.; Miller, D. C. A Model for the Adsorption Kinetics of CO2 on Amine-Impregnated Mesoporous Sorbents in the Presence of Water. Presented at the 28th International Pittsburgh Coal Conference, Pittsburgh, PA, 2011.\n",
"\n",
"The notebook demonstrates how to use the IDAES 1DFixedBed model for an adsorption/desorption application with distinct adsorption and desorption steps. This example leverages custom libraries and functions specific to the NETL_32D solid sorbent and associated gas phase properties and surface reactions. In this system, the silicon monoxide (SiO(s)) sorbent reduces carbon dioxide (CO2(g)) to carbamate (denoted Car(s)) while simultaneously absorbing water vapor (H2O(g)) to produce a solid solution-state hydrate (H2O(s)). The solid phase is considered a one-dimensional domain with three regions for bubble, cloud wake and emulsion properties for bubbling bed systems; in the case of a fixed bed reactor non-bulk gas behavior is neglected and assumed to be homogeneous everywhere not near the solid surface.\n",
@@ -107,7 +107,7 @@
"metadata": {},
"source": [
"\n",
- "### Import Pyomo pakages\n",
+ "### Import Pyomo packages\n",
"For the flowsheet, we will need several components from the pyomo libraries.\n",
"\n",
"- ConcreteModel (to create the Pyomo model that will contain the IDAES flowsheet)\n",
@@ -689,7 +689,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "In the temporal plots below, quantities are reported as functions of time and contoured for six points along the length of the bed. The time and spatial dimensions are exchanged in the spatial plots, with quantities reported as functions of lengh and contoured for five time points.\n",
+ "In the temporal plots below, quantities are reported as functions of time and contoured for six points along the length of the bed. The time and spatial dimensions are exchanged in the spatial plots, with quantities reported as functions of length and contoured for five time points.\n",
"\n",
"The gas flowrate is constant at the inlet and decreases over the length of the bed as CO2 is removed from the gas. At each spatial point, the CO2 content of the gas increases over time as the bed becomes more saturated with CO2 and the mass transfer driving force decreases. Assessing the two gas flowrate plots, adsorption occurs steadily over time with a much larger capture rate in the initial spatial region; this region grows from 10% to 25% of the bed length as the bed becomes more saturated with CO2 over time.\n",
"\n",
@@ -987,7 +987,7 @@
"\n",
"The CO2 content of the gas sharply rises initially, and steadily decreases as CO2 is carried away in the sweep gas. A greater amount of CO2 is recovered closer to the reactor inlet. As the sweep gas is nearly pure water vapor, the water concentration in the gas sharply drops as CO2 is desorbed from the bed and recovers to near unity towards the temporal end of the simulation.\n",
"\n",
- "Carbamate disappears quickly as CO2 is recovered and the hydrate is broken down, occuring evenly across the length of the reactor bed."
+ "Carbamate disappears quickly as CO2 is recovered and the hydrate is broken down, occurring evenly across the length of the reactor bed."
]
},
{
@@ -1109,4 +1109,4 @@
},
"nbformat": 4,
"nbformat_minor": 3
-}
\ No newline at end of file
+}
diff --git a/pyproject.toml b/pyproject.toml
index 779b3940..1f057421 100644
--- a/pyproject.toml
+++ b/pyproject.toml
@@ -143,3 +143,35 @@ markers = [
"needs_solver"
]
testpaths = "idaes_examples"
+
+[tool.typos.files]
+extend-exclude = [
+ "*.svg",
+ "*.json",
+ "*.css",
+ "*.yml",
+]
+
+[tool.typos.default.extend-words]
+# Ignore IDAES
+IDAES = "IDAES"
+# Ignore HDA, assumes it's on purpose and not a typo of "had"
+HDA = "HDA"
+# Ignore Attemp - assume it is abbreviating attemperator
+Attemp = "Attemp"
+# Ignore equil, assumes it's on purpose and not a typo of "equal"
+equil = "equil"
+# Atomic elements
+Nd = "Nd"
+Ba = "Ba" # ba is also used in block names in RSOFC-SOEC example
+# Numpy
+arange = "arange"
+[tool.typos.default]
+extend-ignore-re = [
+ # Jupyter notebooks: ignore hexadecimal values in "id" cell metadata field
+ '"id": "[0-9a-f]+",',
+ # ser is used as a variable name for pd.Series, so we exclude it when followed by a dot
+ # as of 2024-04-25, the false positive are all due to warnings in the output of certain notebooks
+ # which should be resolved regardless (see IDAES/examples#108)
+ "ser[.].*",
+]
diff --git a/tutorial.md b/tutorial.md
index c42aac66..0a1c477b 100644
--- a/tutorial.md
+++ b/tutorial.md
@@ -94,7 +94,7 @@ To demonstrate how the tags work, we will add tags to a couple of these cells:
2. Add the tag `noauto` to the cell with the print statement. This will skip this cell
in the versions of the notebook used for documentation and testing.
3. Add the tag `testing` to the cell with the assert statement. This will only
- include this cell in the version fo the notebook used for testing.
+ include this cell in the version of the notebook used for testing.
### Run preprocessing