Skip to content

Map Constraint.Feasible/Infeasible to concrete constraints #3546

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

Merged
merged 42 commits into from
Jun 4, 2025

Conversation

jsiirola
Copy link
Member

Fixes #2918 .

Summary/Motivation:

We have historically mapped Constraint.Feasible to Constraint.Skip and had Constraint.Infeasible immediately raise a ValueError. This causes some undesirable behavior:

  • You cannot "evaluate" a Constraint that was set by Constraint.Feasible because the ConstraintData was not created (see this question on SO)
  • You cannot (easily) have a trivially infeasible constraint anywhere in the model, even if the infeasible constraint would not cause the model to be infeasible (because it was on a disjunct; see Allow Constraint.Infeasible to be used to disable a Disjunct #2918)

This updates Constraint and LogicalConstraint to map Constraint.Feasible to a trivial inequality, and Constraint.Infeasible to a trivial infeasible Inequality.

Changes proposed in this PR:

  • Map Constraint.Feasible and Constraint.Infeasible to actual trivial constraints
  • Rework part of Constraint to remove a repeated exception
  • Port LogicalConstraint to the new structure (initillizers, disable_method, Abstract classes, simplified method overrides) from Constraint
  • Update logical_to_linear and logical_to_disjunctive to support constant expressions
  • Update tests

Legal Acknowledgement

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

  1. I agree my contributions are submitted under the BSD license.
  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.

@jsiirola jsiirola requested a review from emma58 March 28, 2025 06:39
@jsiirola jsiirola changed the title May Constraint.Feasible/Infeasible to concrete constraints Map Constraint.Feasible/Infeasible to concrete constraints Mar 28, 2025
@michaelbynum
Copy link
Contributor

I feel like I am missing some context for this PR. Other than the example in #2918, I can't think of a use case for Constraint.Infeasible (I would just raise an exception instead of returning Constraint.Infeasible). Having said that, if it is used in a non-GDP model, this PR would postpone an exception to when a solver complains, which would make debugging the model significantly more work. Also, if Constraint.Feasible is used heavily, this PR could lead to unnecessarily large models. Having said that, one can always use Constraint.Skip instead of Constraint.Feasible.

In short, I'm not really a user of Constraint.Feasible or Constraint.Infeasible, but I could see this PR potentially leading to some undesirable effects. Maybe it would be good to discuss when and why these are currently used?

@@ -622,7 +623,9 @@ class Constraint(ActiveIndexedComponent):
class Infeasible(object):
pass

Feasible = ActiveIndexedComponent.Skip
class Feasible(object):
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
class Feasible(object):
class Feasible:

@@ -188,118 +221,94 @@ class LogicalConstraint(ActiveIndexedComponent):
class Infeasible(object):
pass

Feasible = ActiveIndexedComponent.Skip
class Feasible(object):
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
class Feasible(object):
class Feasible:

self.add(expr)
if self.rule is not None:
_rule = self.rule(self.parent_block(), ())
for cc in iter(_rule):
Copy link
Contributor

Choose a reason for hiding this comment

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

What does cc stand for?

Copy link
Member Author

@jsiirola jsiirola May 13, 2025

Choose a reason for hiding this comment

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

Not entirely sure - it is just a temporary, and was copied from the implementation in ConstraintList (and preserved for consistency)

Copy link
Contributor

@emma58 emma58 left a comment

Choose a reason for hiding this comment

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

This is really nice! I'm very happy about the implications for GDP. :) I have a few questions and a couple comments, but mostly just so I understand things.

Comment on lines 451 to 462
# Note that an inequality is sufficient to induce
# infeasibility and is simpler to relax (in the Big-M
# sense) than an equality.
self._expr = InequalityExpression((1, 0), False)
return
elif expr is Constraint.Feasible:
# Note that we do not want to provide a trivial equality
# constraint as that can confuse solvers like Ipopt into
# believing that the model has fewer degrees of freedom
# than it actually has.
self._expr = InequalityExpression((0, 0), False)
return
Copy link
Contributor

Choose a reason for hiding this comment

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

Just so that I understand: Why do we have to put trivial expressions at all? Could we not consider Constraint.Feasible and Constraint.Infeasible to be (weird) relational expression nodes in the expression tree, themselves?

Copy link
Member Author

Choose a reason for hiding this comment

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

We certainly could. That is, we could make Constraint.Feasible and Constraint.Infeasible be singleton expression objects (and not types). I think I would still make them special cases of InequalityExpression, mostly so that all the walkers, writers, and whatnot don't have to be updated to handle them as special cases. This just seemed simpler?

Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe it is simpler, but it's a bit confusing to me why, because it feels like we lose information in this step rather than carrying it through. Because if they were singleton expression objects, then wouldn't we would know after set_value that the Constraint is either non-trivial or it's Constraint.Infeasible or Constraint.Feasible? With this implementation, it could be trivial, and that has to be checked later (by transformations, writers, whatever). Otherwise downstream things would know they either have these special nodes or a non-trivial constraint. Which might be nice...?

Copy link
Member Author

Choose a reason for hiding this comment

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

OK - I have re-implemented Feasible and Infeasible to be singleton inequality expressions. These are preserved and stored in the ConstraintData.expr. This resulted in some baseline changes (the least of which is that the string representation of them is Feasible and Infeasible now). I made a similar change to LogicalConstraint (except that they are singleton BooleanConstant objects).

Comment on lines -397 to +369
def body(self):
def expr(self):
Copy link
Contributor

Choose a reason for hiding this comment

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

Does this PR deprecate body? I agree with the change, but missed the magic somewhere, I think?

Copy link
Member Author

Choose a reason for hiding this comment

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

Nope. .body is still implemented in the LogicalConstraintData base class and is an alias to .expr

@jsiirola jsiirola requested review from mrmundt and emma58 May 20, 2025 15:35
@blnicho blnicho merged commit a8d0bfa into Pyomo:main Jun 4, 2025
35 checks passed
@jsiirola jsiirola deleted the feas-infeas branch June 13, 2025 18:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow Constraint.Infeasible to be used to disable a Disjunct
6 participants