-
Notifications
You must be signed in to change notification settings - Fork 525
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
Scaling transformation does not transform named Expressions #3344
Comments
I am pretty sure it is not mathematically valid to have a scaling factor for an |
How is it not valid to have scaling factors for an The reason we have scaling factors for
Arguably, we shouldn't hijack Pyomo's scaling suffix system for those uses. We'll just have to see what Andrew comes up with to get rid of them (but I think it's going to be harder than he thinks). |
The current scaling transformation behavior is to descend into named expressions while replacing scaled variables in constraints and objectives, and to remove these named expressions. Removing named expressions here seems unnecessary and costly, but was probably done so we don't scale the same named expression twice. Maybe we could:
|
I believe the other reason we removed named expressions was that we couldn't guarantee that there weren't other Constriaints / Objectives outside of the scope of the block that was being transformed that also referred to the same Expression object. Scaling the Expression in place would inadvertently (partially) scale the other Constraint (that was out-of-scope). |
I've found another consequence of the current implementation: the transformed model doesn't get to take advantage of the |
Summary
When a model is transformed using the model scaling transformation,
Expressions
are created on the scaled model, but variable scaling factors are not added to them like they are forConstraints
, resulting in them returning erroneous values. I've encountered this issue twice now and spent significant amounts of time debugging before I realized the scaling transform was the issue.Steps to reproduce the issue
Results:
Information on your system
Pyomo version: 6.7.4.dev0
Python version: 3.10.14
Operating system: Windows 10
How Pyomo was installed: Sources
Solver (if applicable): n/a
Additional information
The behavior I would expect would be to transform the
Expression
like aConstraint
, using a scaling suffix if provided and otherwise just using a value of 1. In that case, both values in the example script should return10.1
. If Pyomo does not want to support scaling ofExpressions
, then it shouldn't even generate them on the scaled model---returning someException
forpyo.value(m_scaled.sum)
.The text was updated successfully, but these errors were encountered: