Issue with DC OPF solve (PowerDiff vs PowerModels)

[karenkji]

It seems PowerDiff fails to solve DC OPF for the IEEE300.m case, but PowerModels is able to solve it successfully.
Created an MRE here of this issue
It provides two test cases: "RTS_GMLC.m" and "IEEE300.m". You can comment out either/or to switch between them. RTS73 DC OPF should succeed with PowerDiff, while IEEE300 fails.

[cameronkhanpour]

Thanks for opening this Karen, I'll try to see if I can replicate this issue on my end.

[cameronkhanpour]

Ok I think the issue is how dc_opf_problem.jl handles the load shed upper and lower bounds, it sets it to 0 \leq psh \leq d, where d is demand.

However, IEEE300.m has buses with negative amount of demand (unlike RTS_GMLC.m), so that upper and lower bound are conflicting with each other. I tried changes the bound to psh \leq max(0, d) and it fixes the issue.

@samtalki let me know if that fix is the right thing to do!

[samtalki]

Ok I think the issue is how dc_opf_problem.jl handles the load shed upper and lower bounds, it sets it to 0 \leq psh \leq d, where d is demand.

However, IEEE300.m has buses with negative amount of demand (unlike RTS_GMLC.m), so that upper and lower bound are conflicting with each other. I tried changes the bound to psh \leq max(0, d) and it fixes the issue.

@samtalki let me know if that fix is the right thing to do!

Thanks to you both. Negative demand, interesting. Yes, your decision seems like the most sensible thing to do to me @cameronkhanpour but I would say we should document that as a design choice in the relevant parts of the docs.

In addition, as our own sanity check, we should take a look at some other typical test cases to see how common negative demands (and other weird features) are and make sure we're robust to those.

Building off of what @karenkji did here, we might also want to make sure we get those other edge cases right relative to PM. Maybe a robust test suite comparing our results to PM's results for those same edge cases for a lot of PGLib networks.