Complementarity-based VLE formulation #977

viiibhav · 2022-10-03T18:15:27Z

Fixes

Summary/Motivation:

This pull request seeks to add the new complementarity-based vapor-liquid equilibrium formulation with thermodynamic models supported by cubic equations of state. Both subcritical and supercritical regimes are supported, but the default is set to subcritical formulation.

Changes proposed in this PR:

Addition of the new formulation and modifying the scripts generic_property.py, smooth_VLE.py, ceos.py and FTPx.py
Addition of critical volume and critical compressibility factor in the property packages BT_PR.py and ASU_PR.py
Incorporation of the above two properties in components.py
Addition of basic unit tests in test_flash_PR.py
Addition of VOLUME_MOL and VOLUME_MASS properties to property_meta.py and test_property_meta.py

Legal Acknowledgement

By contributing to this software project, I agree to the following terms and conditions for my contribution:

I agree my contributions are submitted under the license terms described in the LICENSE.txt file at the top level of this directory.
I represent I am authorized to make the contributions and grant the license. If my employer has rights to intellectual property that includes these contributions, I represent that I have received permission to make contributions and grant the required license on behalf of that employer.

andrewlee94

A few general comments to get things started:

You need to run black on the code before committing, otherwise tests will not get run. I also noted that the branch is out of date with the current main.
Whilst I understand that it is easier to implement in parallel (rather than trying to update the existing code in one go), we should not be committing both versions side-by-side like this (especially not in the "core" parts of IDAES where we want to promise backwards compatibility). For now we should probably work on a branch whilst we refine everything.
This will also make reviewing the code a lot easier - as the files are currently all "new", it is hard to tell what you have changed here, and what is just copied from the original.

jghouse88 · 2022-10-04T14:08:28Z

A few general comments to get things started:

1. You need to run `black` on the code before committing, otherwise tests will not get run. I also noted that the branch is out of date with the current main.

2. Whilst I understand that it is easier to implement in parallel (rather than trying to update the existing code in one go), we should not be committing both versions side-by-side like this (especially not in the "core" parts of IDAES where we want to promise backwards compatibility). For now we should probably work on a branch whilst we refine everything.

3. This will also make reviewing the code a lot easier - as the files are currently all "new", it is hard to tell what you have changed here, and what is just copied from the original.

We deliberately decided not to modify existing code but take it in steps. What do you suggest we do?

andrewlee94 · 2022-10-04T14:16:22Z

@jghouse88 Working on a branch is probably best for now - the alternative would be to put it in models_extra but I am not sure that would be any better. As I noted, a branch will also make it clearer what changes are being made to the files as we can easily see the diff.

However, we definitely should not be merging this into models in the current state.

EDIT: Also, on a branch we can allow tests to fail in the interim period (if required), so we can work directly on the main files and use the test failure to track any issues that still need to be addressed.

jghouse88 · 2022-10-07T15:28:38Z

@andrewlee94 We ideally want to deprecate the older smooth VLE formulation that uses the bubble/dew point. I would rather this go to the models folder than models extra and it languishing there without getting used. What would be necessary in addition to what @viiibhav has done here to get to models?

jghouse88 · 2022-10-07T15:32:29Z

@viiibhav You and I will need to redo this PR to show what changes are happening from the previous version of the CEOS which means you will need to make changes directly to those files and not create a copy with _ncp tag.

andrewlee94

There is a lot to go through here, but here is a first round of comments.

andrewlee94 · 2022-10-12T13:20:17Z

idaes/models/properties/modular_properties/base/generic_property.py

@@ -85,6 +86,7 @@
    _valid_VL_component_list as bub_dew_VL_comp_list,
 )
 from idaes.models.properties.modular_properties.phase_equil.henry import HenryType
+from idaes.models.properties.modular_properties.eos.ceos import Cubic


I do not think we should be using a cubic option as the default here - this seems like something that should be linked to the equation of state chosen. IS there a case where you would want to select this independently of the EoS, or should we just make this part of the EoS module/decision?

The critical_properties can probably be built with other thermodynamic models, but they're not in place yet. Right now, I can calculate them from the method in ceos.py which is the only reason why I am having to import Cubic into generic_property.py. How do I avoid it, and what default value should apply to critical_properties?

I would introduce the critical properties as normal properties. Then, each EoS module would need to define the method to use.

Does that mean it should be treated sort of the same way as phases_in_equilibrium or bubble_dew_method? What I have in mind is that the critical properties method is defined for now in ceos.py. It could stay there, and the property package (eg. ASU_PR.py, BT_PR.py) should specify from where the properties are built.

Not quite, or at least not for now. For now, I would assume that the critical properties method is tied to the EoS chosen, so once you choose the EoS you have chosen the method for critical properties as well.

What I am suggesting is that we treat all critical properties like any other property (e.g., cp_mol_phase). That is , we add the critical properties to the metadata dict with a build-on-demand method which is defined in in the generic StateBlock. This method the calls out to the EoS class for the method to calculate the critical properties, e.g. Cubic.temperature_crit.

Did that help clarify my suggestion?

Yes that helps, thanks Andrew

One little hiccup: the other properties like cp_mol_phase are defined in equation_of_state which is phase-specific. But mixture critical properties are not related to a phase which is why I defined it differently compared to other properties.

Ahh... that issue. That complicates things a bit, as we now need to be able to specify what method to use (similar to bubble_dew_method), but have the added complexity that that method might rely on EoS specific parameters.

So, as a first suggestion, we could have a critical properties argument which we expect to point to an EoS module - w can then do a check to make sure that EoS module is used for at least one of the phases in the system (to keep things simple for now; lets not allow a different EoS for critical properties than is used for a phase in the system).

@dallan-keylogic Any thoughts on this?

My first thought is that the critical point should be calculated for a defined phase equilibrium pair. You can also have critical points for liquid-liquid equilibrium with lower and upper consolute points. I need to take a closer look at this PR to see if that's practical for what you're doing.

@dallan-keylogic I am not sure that makes sense really, and either way doesn't matter until you have a VLLE system. So I wouldn't do that yet (I regret building the framework to try to support multiple liquid phases as it is).

andrewlee94 · 2022-10-12T13:22:52Z

idaes/models/properties/modular_properties/base/generic_property.py

+    CONFIG.declare(
+        "critical_properties",
+        ConfigValue(
+            default=Cubic,


As noted above.

idaes/models/properties/modular_properties/base/generic_property.py

andrewlee94 · 2022-10-12T13:27:12Z

idaes/models/properties/modular_properties/base/generic_property.py

@@ -1133,8 +1154,10 @@ def define_metadata(cls, obj):
                "pressure_osm_phase": {"method": "_pressure_osm_phase"},
                "pressure_sat_comp": {"method": "_pressure_sat_comp"},
                "surf_tens_phase": {"method": "_surf_tens_phase"},
-                "temperature_bubble": {"method": "_temperature_bubble"},
-                "temperature_dew": {"method": "_temperature_dew"},
+                # "temperature_bubble": {"method": "_bubble_dew_method"},


Commented lines - we need to decide what to do with bubble and dew points in general. If we remove the options here, then we should be removing the supporting methods as well (as they won't be used). However, that is a big enough change that it would also require a deprecation warnings and backwards compatibility code.

I suspect the existing methods/libraries might still work with this new formulation, so I would suggest we just keep there here.

idaes/models/properties/modular_properties/base/generic_property.py

andrewlee94 · 2022-10-12T14:58:11Z

idaes/models/properties/modular_properties/base/generic_property.py

-        _temperature_pressure_bubble_dew(b, "pressure_bubble")
+    # -------------------------------------------------------------------------
+    # Critical Properties
+    def _mixture_critical_properties(b):


How does this method get triggered? This looks like it should be set up as a normal build-on-demand property (and critical temperature and pressure should be separate properties).

idaes/models/properties/modular_properties/examples/ASU_PR.py

andrewlee94 · 2022-10-12T15:03:34Z

idaes/models/properties/modular_properties/eos/ceos.py

+                                                   rule=second_derivative)
+
+    @staticmethod
+    def build_critical_properties(b):


I am wondering if this should be set up to be called as a normal build-on-demand property (the code here probably remains the same, we would just change how it gets called).

Do we presently support EoS specific build-on-demand properties?

I don't know that we have any explicit examples, but I don't see why we can't. I think these would be a good example of the need, as calculating the critical point depends on the EoS used.

dallan-keylogic · 2022-10-17T17:51:47Z

idaes/models/properties/modular_properties/phase_equil/smooth_VLE.py

+            doc='Slack variable for cubic second derivative for phase p',
+            units=pyunits.dimensionless),
+    )
+    gn = getattr(b, "gn" + suffix)


FYI, you can replace blocks like this with:

gn = Var(b.params.phase_list, initialize=0.0, bounds=(0, None), doc='Slack variable for cubic second derivative for phase p', units=pyunits.dimensionless) b.add_component("gn" + suffix, gn)

Thanks, I have incorporated this

dallan-keylogic · 2022-10-17T18:57:53Z

idaes/models/properties/modular_properties/phase_equil/smooth_VLE.py

+    def rule_cubic_root_complementarity(b, p):
+        p1, p2 = phase_pair
+        return b.cubic_second_derivative[p1, p2, p] == gp[p] - gn[p]
+    b.add_component(
+        "cubic_root_complementarity" + suffix,
+        Constraint(b.params.phase_list, rule=rule_cubic_root_complementarity),
+    )


If we're directly using things referencing the cubic equation of state, I think this should be made a separate phase equilibrium method. As it stands right now, we can do phase equilibria with the ideal EoS because methods for calculating the bubble and dew points are implemented either from the Antoine equation or Henry's Law (although the Henry's Law implementation is broken at the moment, see #718).

…ference_phase, but hard-coded

…uil initialization to be calculated at subcritical pressure

dallan-keylogic · 2022-10-28T20:56:25Z

idaes/models/properties/modular_properties/base/generic_property.py

+        # ---------------------------------------------------------------------
+        # Initialize temperature_crit_mix and pressure_crit_mix
+        for k in blk.keys():
+            reference_phase = 'Liq'


We shouldn't hard-code phase names like this. It's easy to see places down the road where we have separate aqueous phases and organic phases that are named as such.

Also, it looks like this method is run regardless of whether there are coexisting phases or not. What if the liquid and vapor phases have different equations of state that have different methods of calculating critical properties? I'm still of the opinion that critical properties should be tied to coexisting phase pairs.

On the first point, I agree with @dallan-keylogic ; we should not hard-code names like that. To go a step further, there is nothing stopping someone from naming their liquid phase "foo" (an we explicitly support that).

On the second point, I am not sure that a phase pair is the correct way to go either, precisely for the point @dallan-keylogic raised; what if vapour and liquid have different methods for critical properties (and potentially multiple liquid phases in future)? Rather, my initial feeling is that we need to state a specific phase for calculating the critical properties (i.e., pick vapor or liquid).

As an aside, there might be valid cases where a users wants to take a third option as well (i.e. choose a method for calculating the critical point using something other than the EoS/equivalent for the vapour or liquid phase). I don't think we want to support that for now, but identifying a specific phase would probably make it easier to add support for that in the future.

what if vapour and liquid have different methods for critical properties (and potentially multiple liquid phases in future)? Rather, my initial feeling is that we need to state a specific phase for calculating the critical properties (i.e., pick vapor or liquid).

I was thinking about making the critical properties function something you specify for the phase pair:

# Defining phase equilibria "phases_in_equilibrium": [("Vap", "Liq")], "phase_equilibrium_state": {("Vap", "Liq"): SmoothVLE}, "critical_properties": {("Vap", "Liq"): CubicCriticalProperties},

but other configuration methods are possible.

@dallan-keylogic There are many ways we could do it. AS I was thinking of a response however I realised one good reason why a phase pair is not a good choice; it would only work for multi-phase systems, whilst there might be cases where you want to calculate critical properties for a single phase system.

andrewlee94 · 2022-10-31T11:57:34Z

@viiibhav Also note you have some conflicts to fix (which you should probably do first before they get any worse). These should all be due to some changes I made in how the metadata for units are defined - before they were stored as a dict (derived_units["temperature"]) but now they exist as @properties (derived_units.TEMPERATURE, which supports auto-completion). note that the old approach still works for backward compatibility, but the new approach is preferred.

Also be aware of PR #995, which does a similar thing for thermophsyical properties as well (although there is still a fair bit of work left for that PR to be ready).

idaes/models/properties/modular_properties/phase_equil/smooth_VLE.py

ksbeattie · 2023-02-02T19:49:31Z

@viiibhav is this something that will be ready for the Feb release, meaning ready to merge in the next 2 weeks?

viiibhav · 2023-02-02T19:56:46Z

@ksbeattie probably not, but I will try and get to it.

andrewlee94 · 2023-02-07T17:07:19Z

idaes/models/properties/modular_properties/state_definitions/FTPx.py

@@ -381,6 +381,12 @@ def state_initialization(b):
    henry_comps = []
    init_VLE = False
    for pp in _pe_pairs:
+        # Calculate states at subcritical pressure
+        if b.params.config.supercritical_extension == True:


Does this need to be added to the other state definitions as well?

I don't think so, the other state definitions do not have this calculation. I will test regardless, but hasn't showed up as a problem so far.

…or pressure

ksbeattie · 2023-03-09T19:47:18Z

@viiibhav is this now possible for the May release?

viiibhav · 2023-03-16T18:03:40Z

@ksbeattie yes it should be ready by then.

ksbeattie · 2023-04-27T18:39:59Z

@viiibhav any news on this?

viiibhav · 2023-05-01T03:16:31Z

@ksbeattie Still working on it, was caught up with defense and graduation.

ksbeattie · 2023-05-18T18:59:58Z

Moving this to the Aug release, in hopes it might get done by then.

lbianchi-lbl · 2023-06-29T18:51:42Z

No news as whether this is being worked on for the Aug release.

lbianchi-lbl · 2023-07-13T18:48:56Z

@viiibhav let us know if there are any updates on whether or when you'll be able to resume work on this.

ksbeattie · 2023-07-27T18:56:23Z

@viiibhav closing this due to inactivity.

viiibhav added 2 commits October 3, 2022 13:08

Introducing subcritical ncp formulation for flash

def94f9

Deleting simulation file

e062d40

viiibhav requested review from eslickj, andrewlee94 and jghouse88 October 3, 2022 18:15

viiibhav self-assigned this Oct 3, 2022

andrewlee94 reviewed Oct 3, 2022

View reviewed changes

ksbeattie added the Priority:Normal Normal Priority Issue or PR label Oct 6, 2022

viiibhav added 2 commits October 11, 2022 14:01

Amended original property package scripts and deleted _ncp scripts

4118fe3

Adding black-formatted test script

75c6226

andrewlee94 requested changes Oct 12, 2022

View reviewed changes

andrewlee94 mentioned this pull request Oct 12, 2022

Implement transport properties for modular property framework #976

Merged

dallan-keylogic reviewed Oct 17, 2022

View reviewed changes

viiibhav added 8 commits October 19, 2022 15:42

Changed metre to meter

0cbdb7a

Modified the call to critical properties and Cubic import is removed

3aba1eb

Changed call to supercritical_extension instead of just supercritical

1742351

Changed tbar to _tbar, tbar_constraint to _tbar_constraint

54aa61e

Moved initialization of cubic properties (partially) to ceos. Used re…

5aa473a

…ference_phase, but hard-coded

Cleaned initialization, integrated _pbar, modified state and phase eq…

2fa5910

…uil initialization to be calculated at subcritical pressure

Added terse syntax to create vars

c937653

fixed typo fix --> unfix

c8f7f04

dallan-keylogic reviewed Oct 28, 2022

View reviewed changes

Minor changes to test alternative bubble-dew construction

f6cfd85

dallan-keylogic reviewed Oct 31, 2022

View reviewed changes

idaes/models/properties/modular_properties/phase_equil/smooth_VLE.py Outdated Show resolved Hide resolved

viiibhav added 2 commits December 20, 2022 15:19

Fixed import error

05d5f76

Black formatted again

c27503c

ksbeattie marked this pull request as draft January 12, 2023 19:29

viiibhav added 2 commits January 26, 2023 14:13

Workaround for defining cubic_second_derivative

0936bbe

Minor changes

dc6b1a3

Merge branch 'main' into flash-pr

397d83d

andrewlee94 reviewed Feb 7, 2023

View reviewed changes

viiibhav added 6 commits February 11, 2023 16:11

Standardized names: temperature_crit_mix --> temperature_crit; same f…

8ce8893

…or pressure

Modifications to account for bubble-dew construction changes

fd94de5

Replaced _teq with _tbar

d0b7dfc

Modified bubble-dew construction

c28d75b

Cubic roots involved only with ceos

1cbb139

Run black

540e9a6

dallan-keylogic mentioned this pull request Mar 31, 2023

Add Initializers for most property packages #1153

Merged

lbianchi-lbl mentioned this pull request Jun 22, 2023

Bug in modular properties bubble and dew point calculations #1212

Closed

ksbeattie closed this Jul 27, 2023

ksbeattie added the Backlog Things we'd like to get to someday label Jul 27, 2023

andrewlee94 mentioned this pull request Jul 27, 2023

Implement updated complementarity formulation for VLE #1233

Open

andrewlee94 mentioned this pull request Feb 13, 2024

Support calcuation of critical properties of mixtures in Modular Properties #1336

Merged

andrewlee94 mentioned this pull request Apr 17, 2024

Add new Complementarity formualtion for VLE with cubic EoSs #1397

Merged

Complementarity-based VLE formulation #977

Complementarity-based VLE formulation #977

Conversation

viiibhav commented Oct 3, 2022 • edited Loading

Fixes

Summary/Motivation:

Changes proposed in this PR:

Legal Acknowledgement

andrewlee94 left a comment • edited Loading

Choose a reason for hiding this comment

jghouse88 commented Oct 4, 2022

andrewlee94 commented Oct 4, 2022 • edited Loading

jghouse88 commented Oct 7, 2022

jghouse88 commented Oct 7, 2022

andrewlee94 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

viiibhav Oct 13, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dallan-keylogic Oct 17, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andrewlee94 commented Oct 31, 2022

ksbeattie commented Feb 2, 2023

viiibhav commented Feb 2, 2023

Choose a reason for hiding this comment

viiibhav Feb 7, 2023 • edited Loading

Choose a reason for hiding this comment

ksbeattie commented Mar 9, 2023

viiibhav commented Mar 16, 2023

ksbeattie commented Apr 27, 2023

viiibhav commented May 1, 2023

ksbeattie commented May 18, 2023

lbianchi-lbl commented Jun 29, 2023

lbianchi-lbl commented Jul 13, 2023

ksbeattie commented Jul 27, 2023

viiibhav commented Oct 3, 2022 •

edited

Loading

andrewlee94 left a comment •

edited

Loading

andrewlee94 commented Oct 4, 2022 •

edited

Loading

viiibhav Oct 13, 2022 •

edited

Loading

dallan-keylogic Oct 17, 2022 •

edited

Loading

viiibhav Feb 7, 2023 •

edited

Loading