Generic property package fixes

[alma-walmsley]

Generic property package fixes

• Switch back to the FTPx state definition

  • On closer inspection, FPhx is just an extension of FTPx by providing enth_mol as a variable. It has the exact same variables and constraints when built, except for an extra variable and constraint in FPhx. This means FPhx will not behave any better than FTPx.
    • It actually seems that all the generic property packages are this way, and just provide extra variables to the ports.
    • This also means FPhx doesn't have any special support for solving pure components Peng-Robinson failing to solve pure #9. The idaes docs seems to contradict this though, so might be worth double checking this actually the case. https://idaes-pse.readthedocs.io/en/latest/explanations/components/property_package/general/state/FPhx.html#application
  • Being in FPhx, this increases the complexity of the model for no good reason (+1 variable and constraint). If we want to fix enth_mol, adding a constraint for the expression in FTPx has the same effect.
  • In FPhx, We also have to worry about state bounds for enthalpy.
  • There are no separate initialization methods; they are all built around T and P (recall: T is still a variable in this state definition). But maybe this is not a bad thing? Since we want to be able to use temperature anyway.

• Increase ITER_MAX for estimating temperature_bubble and temperature_dew

  • Fixes "Bubble, dew, and critical point initialization"
  • We were failing due to poor guesses for Tbub and Tdew. Our Tbub guess was higher than the Tdew guess!
  • This was due to hitting the default iteration limit of 30, I increased this to 1000.
  • See also: Generic property package: estimating bubble and dew temperatures IDAES/idaes-pse#1555

• Fix solving with constraints instead of state variables

  • We can set the state_vars_fixed kwarg in the generic property initialization routine to True to indicate that all state variables are fixed, so it won't try to fix them, and instead just does a degrees-of-freedom check.
  • Still faced some issues with deactivation and re-activation of constraints during different steps of the initialization routine (ie. our constraint to define a state variable gets deactivated and isn't activated until later, but it's needed earlier for 0 degrees of freedom). Ended up modifying the initialization routine to allow this, and created a PR to idaes: Generic property package: Using constraints to define state variables IDAES/idaes-pse#1554. I do currently have issues with not fixing pressure (ie. using enth_mol / temperature to define pressure), so maybe this requires some more thought.
  • Extended the fix_state_vars method from idaes.core.util.initialization in the modular property package for handling constraints. We should probably look at doing this for the helmholtz property package as well, since it takes in state_args which are guesses for unfixed variables (provided from control volume initialization). We have probably just been lucky that helmholtz is pretty simple.
  • Added a few different tests for these.

• Add a return value for the constrain method in modular and helmholtz property package

  • Returns either the Var that was fixed, the Constraint that was added, or None if no change
  • This will support https://github.com/waikato-ahuora-smart-energy-systems/Ahuora-Adaptive-Digital-Twin-Platform/pull/963

[alma-walmsley]

Just a heads up @Mahaki-Leach @bertkdowns you can get some nasty infeasible solves if mole_frac_comp does not sum exactly to 1. At T=~403, P=200000, having 0.33 of argon, oxygen, and nitrogen (sum: 0.99) created this flat line in the T - h curve: It is not a small range... 🙂

sum(mole_frac_comp) == 0.99

sum(mole_frac_comp) == 1