Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replacing Expr_if & Changing Bio_P Default #1362

Merged
merged 20 commits into from
May 10, 2024

Conversation

MarcusHolly
Copy link
Contributor

@MarcusHolly MarcusHolly commented Apr 19, 2024

Fixes/Resolves:

Issue #934

Replaces the Expr_ifs in the ASM2d/ADM1 translator block (with the exception of 1 set of Expr_ifs) and changes the bio_P default to False such that the default setting does not set P components to 0 in the translator block.

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.

@MarcusHolly MarcusHolly added the Priority:Normal Normal Priority Issue or PR label Apr 19, 2024
@MarcusHolly MarcusHolly self-assigned this Apr 19, 2024
@MarcusHolly MarcusHolly marked this pull request as ready for review April 19, 2024 15:49
Comment on lines +638 to 640
# TODO: Can this be replaced with smooth_max or smooth_min?
@self.Expression(self.flowsheet().time, doc="Protein mapping")
def Xpr_mapping(blk, t):
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if this (and line 1039) can be expressed as a smooth_max or smooth_min

blk.properties_in[t].conc_mass_comp["S_F"] - blk.SN_org[t],
blk.eps,
)
Copy link
Contributor

@luohezhiming luohezhiming Apr 22, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am a little confused here, I think the original equation, if A>=B, then we have eps, but in the the smooth_max function, you directly change this eps to 0 if I understand correctly, and the eps in the smooth_max function is smoothing parameter set at 1e-10. My first question is: does change previous eps to 0 have no impacts to all of the examples? And why do you set 1e-10 for the smoothing parameter

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Setting eps to 0 means it is no longer smooth, and can thus trigger numerical issues.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So there are two instances of eps in this file. eps is 0 and blk.eps is 1e-10. blk.eps is the one used in the smooth_max and smooth_min functions. I think I should just directly replace instances of eps with zero to make this less confusing

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@luohezhiming I changed the epsilon used for smooth_max and smooth_min to eps_smooth to make things a bit more transparent. Also, the 1e-10 is the smoothing factor used in the ASM1/ADM1 translator, so I just carried that value over. It can be changed if necessary.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@MarcusHolly You should not be using eps=0 in the smoothmax and smoothmin functions - that defeats the entire purpose if those functions. If you really want a non-smooth max or min then you should refactor these to use Expr_if.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

eps=1e-10 in the smooth_max. Are you saying it shouldn't be that close to 0 @andrewlee94?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably not - the value you use for eps represents how smooth the operation is. Smaller values mean less smoothness and thus more chance for numerical issues (but less numerical error). Ultimately, eps needs to be tuned for the application, and should be a few orders of magnitude less than the inputs to the max operation.

Copy link
Contributor Author

@MarcusHolly MarcusHolly Apr 23, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed the eps_smooth value to 1e-4 since this seems to give the best solver performance in the BSM2_P_extension.py flowsheet.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the eps now only represents the smoothing parameter, we can try to vary the smooth_eps if all tests get passed.

@MarcusHolly MarcusHolly marked this pull request as draft April 23, 2024 15:13
@MarcusHolly
Copy link
Contributor Author

When eps_smooth is 1e-10, the BSM2_P_extension test fails locally but passes the check here; however, when eps_smooth is 1e-4, the BSM2_P_extension test passes locally but fails the check here. Any thoughts @andrewlee94 or @adam-a-a ?

@andrewlee94
Copy link
Collaborator

@MarcusHolly That is indicative of poor scaling. What do the diagnostics tools tell you?

@MarcusHolly
Copy link
Contributor Author

@MarcusHolly That is indicative of poor scaling. What do the diagnostics tools tell you?

The scaling is definitely poor and/or non-existent in some places - this is a known issue. The DiagnosticToolbox identified 155 potential evaluation errors and variables/constraints with extreme jacobians, but none of these are new issues and are also present in the version currently merged in main.

Copy link

codecov bot commented Apr 26, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 93.85%. Comparing base (77d56e6) to head (0cc70ea).

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #1362   +/-   ##
=======================================
  Coverage   93.84%   93.85%           
=======================================
  Files         339      339           
  Lines       35887    35928   +41     
=======================================
+ Hits        33679    33720   +41     
  Misses       2208     2208           

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

@MarcusHolly MarcusHolly marked this pull request as ready for review April 27, 2024 00:27
@MarcusHolly MarcusHolly changed the title Replacing Expr_if in ASM2d/ADM1 Translator Replacing Expr_if & Changing Bio_P Default Apr 27, 2024
@MarcusHolly MarcusHolly marked this pull request as draft May 2, 2024 21:07
@MarcusHolly MarcusHolly marked this pull request as ready for review May 3, 2024 18:59
@MarcusHolly
Copy link
Contributor Author

MarcusHolly commented May 3, 2024

@luohezhiming I've added a config option into the flowsheet so that the user can specify whether to use bio_P=True or bio_P=False.

@luohezhiming
Copy link
Contributor

@luohezhiming I've added a config option into the flowsheet so that the user can specify whether to use bio_P=True or bio_P=False.

Looks good, Let's see if tests will get pass

Copy link
Contributor

@luohezhiming luohezhiming left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Does all tests will pass with (using the new tear_guesses) bioP=True?

Copy link
Contributor

@agarciadiego agarciadiego left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Contributor

@adam-a-a adam-a-a left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My general question is how do the changes affect flowsheet convergence? I'd be interested to know, e.g., the number of iterations to solve before and after the changes, notable differences in IPOPT output, or anything of that nature. It would just be informative for all involved I think.

}
if bio_P:
# Initial guesses for flow into first reactor
tear_guesses = {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How did you arrive at these new guesses?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I got the initial guesses from Chenyu's ElectroN-P flowsheet, and then I made some very slight modifications to them.

@MarcusHolly
Copy link
Contributor Author

My general question is how do the changes affect flowsheet convergence? I'd be interested to know, e.g., the number of iterations to solve before and after the changes, notable differences in IPOPT output, or anything of that nature. It would just be informative for all involved I think.

Before changes (Bio_P = True):
image

After changes (Bio_P = True):
image

After changes (Bio_P = False):
image

@andrewlee94
Copy link
Collaborator

That is a lot of iterations for solving a square problem - if IPOPT needs more than 50 iterations (and in practice often far fewer) on a square problem it often indicates the model has issues that should be resolved.

@adam-a-a
Copy link
Contributor

That is a lot of iterations for solving a square problem - if IPOPT needs more than 50 iterations (and in practice often far fewer) on a square problem it often indicates the model has issues that should be resolved.

While we know that this model is problematic, we are continuously refining it as we go. We also suspect that poor scaling is significantly hampering the model. This flowsheet would actually be a great (and likely challenging) test case for the new scaling tools underway. In any case, we're making incremental improvements with every PR (or at least trying to).

@lbianchi-lbl lbianchi-lbl enabled auto-merge (squash) May 10, 2024 14:22
@lbianchi-lbl lbianchi-lbl merged commit ac04ca7 into watertap-org:main May 10, 2024
23 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority:Normal Normal Priority Issue or PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants