CSTR Re-Scaling

[MarcusHolly]

Summary/Motivation:

Adds the new IDAES scaling routine (scaler objects) to the CSTR & CSTR w/Injection unit models.

Changes proposed in this PR:

• Updates the scaling routine of the CSTR unit models
• Updates the associated testing files

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.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 93.68%. Comparing base (3d2c4a0) to head (cd5c8fa).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1542   +/-   ##
=======================================
  Coverage   93.67%   93.68%           
=======================================
  Files         278      278           
  Lines       30262    30297   +35     
=======================================
+ Hits        28348    28383   +35     
  Misses       1914     1914           

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

[MarcusHolly]

@TimBartholomew @adam-a-a @dallan-keylogic

Based on the scaling discussion yesterday, the latest commit added some preliminary testing using the Scaling Profiler for these three unit models using the new scaling tools (Scaler objects) and the old scaling tools (iscale). I think it might make the most sense for this and similar PRs of mine to get all the Scalers and tests in place while subsequent PRs can refine the tests and scaler objects as necessary (e.g. adjusting unit model variable/constraint_scaling_routine, adjusting property model variable/constraint_scaling_routine, solution pertubation when using the ScalingProfiler, etc.)

Any advice/comments on this and does it still make sense to keep tests making the overly simplistic comparison between the Jacobian condition numbers for the old and new scaling tools?

If you all are still planning on meeting to discuss this topic "soon", I'd be happy to tag along as well.

[adam-a-a]

@TimBartholomew @adam-a-a @dallan-keylogic

Based on the scaling discussion yesterday, the latest commit added some preliminary testing using the Scaling Profiler for these three unit models using the new scaling tools (Scaler objects) and the old scaling tools (iscale). I think it might make the most sense for this and similar PRs of mine to get all the Scalers and tests in place while subsequent PRs can refine the tests and scaler objects as necessary (e.g. adjusting unit model variable/constraint_scaling_routine, adjusting property model variable/constraint_scaling_routine, solution pertubation when using the ScalingProfiler, etc.)

Any advice/comments on this and does it still make sense to keep tests making the overly simplistic comparison between the Jacobian condition numbers for the old and new scaling tools?

If you all are still planning on meeting to discuss this topic "soon", I'd be happy to tag along as well.

Great job on putting those changes so quickly! I agree with your thought on refining as needed in subsequent PRs. As for the comparison of condition numbers, I don't see any harm in keeping them for now since they give us some sort of benchmark.

[adam-a-a]

Is injection another variable that should be covered here? I was thinking this Scaler looks almost the same (if not the same) as that of the CSTR, but injection is what sets this model apart from the regular cstr.

[MarcusHolly]

For this to work, I would need to add something like the following code into the CSTR_InjectionScaler class, but I'm not sure how to get this working (how to get it to read the has_aeration config option and whether or not S_O or S_O2 exist)

        if self.config.has_aeration:
            # Assuming that the supplied property package doesn't have both S_O and SO2 to represent oxygen.
            if "S_O" in self.config.property_package.component_list:
                self.scale_variable_by_default(
                    model.control_volume.mass_transfer_term[0, "Liq", "S_O"], overwrite=overwrite
                )
            elif "S_O2" in self.config.property_package.component_list:
                self.scale_variable_by_default(
                    model.control_volume.mass_transfer_term[0, "Liq", "S_O2"], overwrite=overwrite
                )
            else:
                pass

[MarcusHolly]

From a theoretical perspective, I've only been adding default scaling for variables that don't usually vary by orders of magnitude. For instance, volume for these units will usually be on the order of 1e3 (based on historical usage). However, I'm not as confident with injection. Should we expect this variable to consistently be on the order of 1e-2 or will it vary depending on the application. If the latter, we should probably avoid applying a default scaling factor here.