You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The MCAS property model has the following constraint formulation (line 1464):
def rule_mass_frac_phase_comp(b, p, j):
return b.mass_frac_phase_comp[p, j] == b.flow_mass_phase_comp[p, j] / sum(
b.flow_mass_phase_comp[p, j] for j in self.params.component_list
)
This leads to a potential division by zero as flow goes to zero and thus would be better reformulated as:
def rule_mass_frac_phase_comp(b, p, j):
return b.flow_mass_phase_comp[p, j] == b.mass_frac_phase_comp[p, j] * sum(
b.flow_mass_phase_comp[p, j] for j in self.params.component_list
)
However, doing this results in issues with the scaling methods, primarily due to the transform_property_constraints function which assumes that all constraints are written in the form of property = function(). I suspect that this might have further reaching effects than just this.
Motivation
Generally, constraints should be formulated in ways to avoid potential singularities, such as avoiding divisions where possible (unless the denominator is a simple constant). Doing so helps avoid numerical issues during solving and will generally make models more robust (and often better scaled).
Possible Implementation
This issue effectively has two parts:
Looking for poorly formulated constraints and rewriting them (relatively easy, especially with the diagnostics tools), and
Updating the scaling routines to accommodate these changes (somewhat more effort, especially with the above mentioned transform_property_constraints function). However, given the current push to using the new Scaler classes this hopefully becomes much easier (or at least can be done at the same time).
Additional Context
No response
The text was updated successfully, but these errors were encountered:
Description
The MCAS property model has the following constraint formulation (line 1464):
This leads to a potential division by zero as flow goes to zero and thus would be better reformulated as:
However, doing this results in issues with the scaling methods, primarily due to the
transform_property_constraints
function which assumes that all constraints are written in the form ofproperty = function()
. I suspect that this might have further reaching effects than just this.Motivation
Generally, constraints should be formulated in ways to avoid potential singularities, such as avoiding divisions where possible (unless the denominator is a simple constant). Doing so helps avoid numerical issues during solving and will generally make models more robust (and often better scaled).
Possible Implementation
This issue effectively has two parts:
transform_property_constraints
function). However, given the current push to using the newScaler
classes this hopefully becomes much easier (or at least can be done at the same time).Additional Context
No response
The text was updated successfully, but these errors were encountered: