Bridges don't update when other constraints updated

[odow]

Bridges are self-contained objects; they take a variable/constraint/objective as input, and produce a collection of variables/constraints/objective as output.

This works for most use-cases, but there are a few edge-cases that we haven't solved:

Epigraph bounds

We can bridge [z, x, y] in SecondOrderCone() to x^2 + y^2 <= z^2 and z >= 0.

• What happens if we try adding a different constraint to z? Like EqualTo? The inner MOI model can't have two lower bounds, but it's fine for the outer model.
• One solution is to add a linear constraint 1z >= 0, but some solvers might need an explicit bound on z to infer convexity.

Variable transforms

We can bridge x in Semicontinuous(l, u) to z in {0, 1}, x >= l * z, x <= u * z.

• Now the inner x is a free variable. What happens if we add a second constraint to x like a lower bound? At the moment everything works because the bridge forwards the bound and the inner model happily accepts it. The bridge needs a way to "seeing" this in order to throw a BoundAlreadySet error.

This is issue #1431.

Here's another example from Hypatia: jump-dev/Hypatia.jl#784

Solution

@blegat started a solution here:

• Add variable constraint watcher bridges #1097
• Throw error when bounds are set from Semi... bridges #1095

At some point in the MOI 1.x timeframe, we should come up with a comprehensive solution to this problem.

[dourouc05]

Another problem that is really related to this: for CP bridges, some properties are needed for bridges to operate (like ensuring that variables are integer or binary, have lower and/or upper bounds). For instance, this is required to ensure that a given variable in an indicator constraint is really binary or to compute appropriate big-M values (instead of relying on some arbitrarily large value that will fail for some models, leaving the user wonder why it started to fail). If the corresponding information is not yet available when the bridge is called, its execution fails (only because the whole transformation is called too soon), or it should start to fail at some point.

I think that #1097 would be a very reasonable solution, based on existing design patterns.