DCPPowerModel working with DirectMode

[jd-lara]

When making a model using direct mode and DCPPowerModel the compatibility of affine in interval throws an expected error at the MOI level

┌ Error: Failed to build UC
└ @ PowerSimulations ~/.julia/packages/PowerSimulations/cYxdM/src/simulation/simulation.jl:344
┌ Error: Simulation build failed
│   exception =
│    Constraints of type MathOptInterface.ScalarAffineFunction{Float64}-in-MathOptInterface.Interval{Float64} are not supported by the solver.
│    
│    If you expected the solver to support your problem, you may have an error in your formulation. Otherwise, consider using a different solver.
│    
│    The list of available solvers, along with the problem types they support, is available at https://jump.dev/JuMP.jl/stable/installation/#Supported-solvers.

I wonder if the formulation can be adjusted to support direct mode.

[odow]

Which solver? Gurobi? If so: this is expected behavior.

In no case is this a bug in PowerModels.jl. It's strictly an issue for whatever solver you are using.

[jd-lara]

Which solver? Gurobi? If so: this is expected behavior.

In no case is this a bug in PowerModels.jl. It's strictly an issue for whatever solver you are using.

Yes, Gurobi and Xpress. I know this is expected for the way that the DCPPowerModel is formulated. I am asking if the formulation can be reimplemented to use inequalities such that It becomes compatible with direct_mode.

I think the issue stems from the use of bounds on expressions here

https://github.com/lanl-ansi/PowerModels.jl/blob/be6af59202a6868b20a41214cb341b883d62e5f0/src/form/shared.jl#L72

[odow]

Okay: this is a pretty nuanced discussion point: to what extent should PowerModels change its formulations to support models more closely implemented by the solver, and to what extent should we complicate the solver wrappers by adding support for a wider range of constraints.

See the last paragraph of page 11: https://arxiv.org/pdf/2002.03447

[odow]

I took another look at this to see if Gurobi had changed. It hasn't. While it appears to have support for interval constraints, it actually implements l <= f(x) <= u as f(x) - y = 0; l <= y <= u, and it exposes y to the user, which makes tracking the number of variables and their order much more complicated than it needs to be.

Docs:

https://docs.gurobi.com/projects/optimizer/en/current/reference/c/model.html#c.GRBaddrangeconstr

[jd-lara]

I get your point, we had to make similar compromises in PowerSimulations.jl to add explicit ub and lb constraints instead of range ones precisely because of the solver's compatibility with MathOptInterface.ScalarAffineFunction{Float64}-in-MathOptInterface.Interval{Float64}. I just think in this case it is less controversial since there is no loss of interpretability nor does it affect the performance of the build or solve model to change the implementation to two inequalities instead of a range.

[jd-lara]

I took another look at this to see if Gurobi had changed. It hasn't. While it appears to have support for interval constraints, it actually implements l <= f(x) <= u as f(x) - y = 0; l <= y <= u, and it exposes y to the user, which makes tracking the number of variables and their order much more complicated than it needs to be.

Docs:

https://docs.gurobi.com/projects/optimizer/en/current/reference/c/model.html#c.GRBaddrangeconstr

I wonder what's more effective two inequalities or Gurobi's change in equations...

[odow]

I wonder what's more effective two inequalities or Gurobi's change in equations...

Open question. Presolve probably makes them equivalent.

[odow]

The downside to making this change is that it makes solvers like Ipopt worse off.

I wonder if we need logic to decide which formulation it supports. But then we're making PowerModels more complicated... trade-offs without a clear answer.

[odow]

There are at least 10 instances that could be changed:

Is there any motivation to do only a subset?

[ccoffrin]

I am not sure I fully follow the issue but here is a possibly misguided thought.

Is there a way for the user of PowerModels to direct jump to implement a special bridge for l <= f(x) <= u constraints, so when they arrive at Gurobi they are compatible with direct mode?

[odow]

so when they arrive at Gurobi they are compatible with direct mode?

They can use something like:

optimizer = MOI.Bridges.Constraint.SplitInterval{Float64}(
    Gurobi.Optimizer(),
)
model = direct_model(optimizer)

but this pretty clunky.

The bigger underlying problem is that there are variations in the standard form between solvers. How hard should PowerModels try to support the native problem types for different solvers?

[jd-lara]

so when they arrive at Gurobi they are compatible with direct mode?

They can use something like:

optimizer = MOI.Bridges.Constraint.SplitInterval{Float64}( Gurobi.Optimizer(), ) model = direct_model(optimizer) but this pretty clunky.

The bigger underlying problem is that there are variations in the standard form between solvers. How hard should PowerModels try to support the native problem types for different solvers?

is adding a simple MOI.supports to the constraint creation to choose one or the other that much more complicated? At the end of the day you need to change all the occurrences, just the ones where the model can have only linear constraints. ACP, ACR, etc don't need to change.