IX model small fix for anions in demo

[kurbansitterley]

Fixes/Resolves:

While writing the docs for the IX flowsheet, the anion demos would not solve easily (we were not testing them). This is a quick fix for easier solvability of the anions in the IX demo flowsheet.

Summary/Motivation:

Ensure the IX demo will work for the anions.

Changes proposed in this PR:

• use abs(value(charge)) to calculate mass_removed for IX langmuir model
• add test to demo test file for SO4_2- to cover bases

Legal Acknowledgement

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

1. I agree my contributions are submitted under the license terms described in the LICENSE.txt file at the top level of this directory.
2. 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.

[kurbansitterley]

This issue was likely making the Langmuir IX model unsolvable for anions since it was calculating a negative value for mass_removed due to the negative charge. This was not caught because we weren't testing for that configuration. Lesson learned.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.01%. Comparing base (271e43b) to head (9e06637).
Report is 51 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1420   +/-   ##
=======================================
  Coverage   94.01%   94.01%           
=======================================
  Files         335      335           
  Lines       35561    35570    +9     
=======================================
+ Hits        33431    33442   +11     
+ Misses       2130     2128    -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[adam-a-a]

don't know if this would be overkill, but would it be safer to use smooth_abs? One potential scenario could be that the charge for a particular component is unknown, and we set it as a var to estimate. I think in that case, you'd want something like smooth_abs. I don't know how likely that scenario is, but just thinking out loud on whether we think it's fine to just use abs here for the long run.

[bknueven]

Maybe the compromise is to use pyo.environ.abs.

If this value is fixed but the user updates it for some reason you'll still get the correct value put to the solver.

[andrewlee94]

smooth_abs would have no effect in this case as written as you are using value inside the abs; i.e. it is effectively a constant and not a variable. However, that does lead me to ask if this is the intended behaviour, as with the value in there this is now just a constant and thus will not change if the value of the variable is changed later.

[kurbansitterley]

don't know if this would be overkill, but would it be safer to use smooth_abs? One potential scenario could be that the charge for a particular component is unknown, and we set it as a var to estimate. I think in that case, you'd want something like smooth_abs. I don't know how likely that scenario is, but just thinking out loud on whether we think it's fine to just use abs here for the long run.

A target_ion with an unknown charge should raise a ConfigurationError for this model. I also think if we were in a situation where we were trying to predict the charge of an unknown component, we would likely need a different model.

[kurbansitterley]

Maybe the compromise is to use pyo.environ.abs.

If this value is fixed but the user updates it for some reason you'll still get the correct value put to the solver.

I tried this initially (i.e., from pyomo.environ import abs) and it resulted in an ImportError. Could it exist elsewhere in pyomo?

[kurbansitterley]

smooth_abs would have no effect in this case as written as you are using value inside the abs; i.e. it is effectively a constant and not a variable. However, that does lead me to ask if this is the intended behaviour, as with the value in there this is now just a constant and thus will not change if the value of the variable is changed later.

Yes this is the intended behavior - the value of charge_comp (a Param) must be either positive or negative to use the model, and would be set as part of the configuration of the property package (it is checked at the beginning of the build for this model) . It is assumed it is a fundamental property of the solute and wouldn't change later.

[adam-a-a]

True, it is currently a Param. I guess I was just thinking of a use case of my own, where I might need to set charge_comp as a Var for parameter estimation since, in that use case, the charge is unknown (just know it should be negative). But- right now charge_comp is just a Param so shouldn’t matter at this point.

[bknueven]

Is prop_in.charge_comp[j] a parameter which should never change?

[kurbansitterley]

Correct, should never change and is set as part of the property package configuration.

[bknueven]

Maybe the compromise is to use pyo.environ.abs.

If this value is fixed but the user updates it for some reason you'll still get the correct value put to the solver.